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Descubrimiento y divulgación responsable de fallos de seguridad en software 
de servidor web «CVE-2006-1681» y en dispositivo de seguridad perimetral «CVE- 
2013-6830 y CVE-2013-6031», así como fallos en webs de empresas de diferentes 
niveles de riesgo, notificadas responsablemente a los mismos. 








INTRODUCCIÓN 


Existe muchísima documentación sobre lenguajes ensamblador de todas y 
cada una de las arquitecturas del mercado. En todas ellas se detalla la función de 
cada una de las instrucciones así como su forma de uso. Por otro lado, también 
existen muchos libros sobre lenguajes de programación de más alto nivel como 
C/C++, dónde se explican todas las estructuras de control, variables y tipos de 
datos, funciones, clases y demás funcionalidades de la programación. Además de 
esto existen disciplinas y material bibliográfico para saber transformar el código 
de lenguajes de alto nivel, a código ensamblador (compiladores). ¿Es el código 
compilado reversible? ¿Con que nivel de certeza? ¿Es literal el código obtenido al 
inicial? Todas estas preguntas y el proceso de invertir el código compilado, es de lo 
que se trata el presente libro, también conocido como Ingeniería Inversa. 


La utilidad de un proceso así es variado y se explica y discute en profundidad, 
incluyendo sus aspectos legales en el primer capítulo. No obstante hay que recalcar 
que de manera casi general, se puede decir que la Ingenieria inversa se lleva a cabo 
para obtener conocimiento en detalles y concreto sobre el funcionamiento de un 
software en cuestión. La motivación que lleva a su obtención o el uso que se haga del 
mismo, es algo tan variado como cada uno de los casos que se abordan. 


El objetivo de este material no es solo hacer un repaso sobre teoría de 
compiladores, funcionamiento interno de los depuradores, desensambladores, 
formato de ficheros binarios y el análisis en profundidad sobre las estructuras de 
control, tipos de datos y demás. El objetivo principal del libro es dotar al lector de 
las herramientas necesarias para poder llevar a cabo labores de ingeniería inversa por 
sus propios medios y comprendiendo en cada momento lo que sucede, sin toparse 
con barreras técnicas a las que no pueda enfrentarse. 
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Elúltimo capítulo, expone tres casos prácticos, dónde el lector podrá poneren 
práctica lo aprendido enfrentándose a situaciones reales y para las que el autor lleva 
a cabo su resolución con todo detalle, tanto en lo técnico como en el razonamiento 
utilizado para llegar al final del problema. Es sin duda este enfoque, el que hace de 
este libro una guía perfecta para el correcto aprendizaje de esta complicada pero 
interesante disciplina. 





El material de este libro forma parte del Master de CiberSeguridad de 
Deloitte, impartido por CyberSOC Academy. El autor, forma parte del grupo de 
Hacking Ético de Deloitte y lleva a cabo test de intrusión a empresas nacionales e 
internacionales. 








INTRODUCCIÓN A LA 
INGENIERÍA INVERSA 


Introducción 





En esta unidad didáctica definiremos el concepto de la ingeniería inversa, en 
concreto en el mundo de la informática y las telecomunicaciones. Para ello veremos 
conceptos relacionados con la ingeniería del sofware, y se explicará, a través de su 
historia y otras circunstancias, la motivación por la que es necesario realizar este tipo 
de acciones sobre un sofware. Por último, se expondrán las limitaciones técnicas de 
esta disciplina, así como las limitaciones legales que se imponen sobre ellas. 


Objetivos 


Cuando el alumno haya concluido la unidad didáctica, será capaz de 
comprender el porqué de la ingeniería inversa, en qué condiciones es posible llevarla 
a cabo y será capaz de realizar este tipo de acciones desde la legalidad actual. 


1.1 DEFINICIONES 





Definición 


La ingeniería inversa, conocida en el mundo anglosajón simplemente como 
reversing: 
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теуег$е (түз:в © ) 


> Definitions 
verb (mainly pensite) 





recon. onder, or poston 


Definición “reversing” 


Se refiere a dar la vuelta al proceso de elaboración de un producto final. 
En este caso que nos ocupa, se viene a referir a un software compilado del cual 
se carece de cualquier tipo de código fuente, esquemas de diseño, pseudocódigo, 
especificaciones o cualquier tipo de información referente al funcionamiento interno. 
del software. 


En castellano nos referimos a ello como ingeniería inversa, refiriéndonos al 
proceso inverso de ingeniería. Según se extrae de la Real Academia Española: 


ingeniería. 
1. £ Estudio y aplicación, por especialistas, do las divorsas ramas do la tecnología. 


Definición “reversing” 


Definición “ingeniería” 





La ingeniería es el conjunto de conocimientos y técnicas, científicas aplicadas 
al desarrollo, implementación, mantenimiento y perfeccionamiento de estructuras 
(tanto físicas como teóricas) para la resolución de problemas que afectan la actividad 
cotidiana de la sociedad. 








En este contexto, nos referimos en concreto a la ingenieria del software, 
cuya definición puede verse descrita en la Wikipedia: 


“Ingeniería de sofiware es la aplicación de un enfoque sistemático, 
disciplinado y cuantíficable al desarrollo, operación y mantenimiento de software, 
y el estudio de estos enfoques, es decir, la aplicación de la ingeniería al software 
Integra matemáticas, ciencias de la computación y prácticas cuyos origenes se 
encuentran en la ingeniería” 
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La ingenieria del sofware lleva un proceso de diseño, desarrollo ¢ 
implementación de soluciones que conlleva un tiempo y esfuerzo considerable. El 
software final es el resultado de todo ese conocimiento e investigación sobre la mejor 
solución al problema para el que está pensado. 


Como ejemplo, se puede ver el modelo unificado de desarrollo de software, 
que es un proceso genérico y puede ser utilizado para una gran cantidad de tipos 
de sistemas de software, para diferentes áreas de aplicación, diferentes tipos de 
organizaciones, diferentes niveles de competencia y diferentes tamaños de proyectos. 


Provee un enfoque disciplinado en la asignación de tareas y responsabilidades 
dentro de una organización de desarrollo. Su meta es asegurar la producción de 
software de muy alta calidad que satisfaga las necesidades de los usuarios finales, 
dentro de un calendario y presupuesto predecible. 


El siguiente diagrama extraído, muestra de manera gráfica el proceso de 


elaboración de un software concreto que responda a unas necesidades, presupuesto 
y tiempo conereto. 


Inicio del > 
Proyecto 


l 





INICIO 





+ Incrementos = ип caso de uso сом. 


+ iteración = un caso de uso refinado 
con toda la funcionalidad 


Versión 1, Versión 2, ... 





Modelo Unified Process 
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En él se puede ver cómo tras su liberación, el proceso es circular y continuo, 
de tal forma que es posible seguir agregando funcionalidades al software, siguiendo 
«1 mismo esquema. De esta forma, y mientras este proceso continuo no se paralice, 
es posible continuar agregando funcionalidades y mejorar el sofware final. 


Sin embargo, todo ese conocimiento y resultados de investigación, no son 
directamente extraíbles del sofhware final. Simplemente es una caja negra que recibe 
unas entradas y devuelve unas salidas óptimas para resolver el problema propuesto, 
pero no extrapolable a otros casos. Es necesario volver a introducir esos datos para 
poder conseguir el resultado basado en el conocimiento del software en cuestión. 


Si se pretende extraer todo ese conocimiento y lógica de funcionamiento, es 
necesario analizarlo desde dentro. 


Historia 


La ingeniería inversa como tal no nació en el mundo de la ingeniería del 
software. Desde que se han fabricado aparatos o dispositivos mecánicos, el interés 
por conocer su funcionamiento interno y detallado ha motivado a otros individuos lo 
suficiente como para llevar a cabo procesos de ingeniería inversa para comprender 
el funcionamiento. 


Un caso similar, aunque no exactamente aplicable, es el de la decodificación 
de escritos antiguos, donde el punto de partida cra un texto ya escrito con un 
significado desconocido, y mediante el análisis, la comparación y deducción, se lleva 
a cabo el descifrado y comprensión del texto así como su contenido. 





Antiguos pero más relacionados son los casos de herramientas o las primeras 
máquinas utilizadas en agricultura, que fueron analizadas por otros individuos que 
nunca las habían visto y que no conocían de su existencia, y de esta forma pudieron 
no solo hacer uso de ellas, sino incluso mejorarlas. 


Otro ejemplo muy conocido de ingeniería inversa, fue el aplicado a la 
máquina Enigma, utilizada en la Segunda Guerra Mundial para cifrar los mensajes 
alemanes: 


En los Estados Unidos de América se llevó a cabo un proceso de ingeniería 
inversa sobre las máquinas Enigma que pudieron requisar o encontrar. Se dice que 
gracias a que se pudo analizar la máquina, todos los detalles de implementación y 
fabricación, y finalmente el algoritmo de cifrado de la misma, se pudo finalizar la 
guerra dos años antes de lo esperado. 
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Enigma 


En ambientes bélicos y militares de cualquier época, ha sido importante 
recuperar utensilios y armamento del enemigo para poder analizarlos y tener mayor 
conocimiento, no solo práctico sobre herramientas y armas, sino a cerca del nivel de 
sofisticación del enemigo. 





En épocas más avanzadas donde las armas conllevan información valiosa, En 
el ejemplo de Enigma, el aparato lleva consigo el algoritmo de cifrado y descifrado 
utilizado para cifrar los mensajes. Esto significa que el enemigo no solo podría 
reproducir una máquina similar para cifrar también sus mensajes, sino que son 
capaces de descifrar los de sus enemigos sin que estos lo sepan, ya que pensarian que 
el cifrado es seguro y que aunque las máquinas scan “destripadas” no sería posible 
obtener el algoritmo de cifrado. Esto les creó una falsa sensación de seguridad a los 
alemanes, que finalmente acabaron padeciendo. 











Actualmente, los dispositivos militares tales como armas, dispositivos 
de comunicaciones, dispositivos de transporte o exploración, contienen mucha 
información valiosaparasusenemigos.Códigosy frecuencias aralascomunicaciones, 
geolocalizaciones, y el dispositivo en sí que suele ser tecnológicamente superior a 
tros similares de uso civil. Si toda esta información es sometida a tareas de ingeniería 
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inversa y criptoanálisis, es posible disponer de información muy valiosa que pueda 
aventajar al enemigo en una operación en concreto, batallas o incluso guerras. 


Un caso relativamente reciente sucedió en diciembre de 2011, cuando 
Irán capturó un dron RỌ -170 Sentinel estadounidense, tras estrellarse por un 
fallo mecánico, y estos consiguieron decodificar todas las memorias y sistemas 
informáticos del vehiculo aéreo. Pudiendo así fabricar otro modelo de vehiculo no 
tripulado basado en este, con algunas mejoras al respecto. Se puede consultar la 
noticia original en el siguiente enlace: 


S http:llenglish farsnews.com/newstext. aspx?nn=13920631000264 


Estos casos de espionaje han creado la necesidad de fabricar dispositivos y 
microchips que puedan ser autodestruidos de manera remota o basado en cuenta atrás. 
Para ello DARPA (Defense Advanced Research Projects Agency) otorga casi cuatro 
millones de dólares a IBM para fabricar microchips de bajo coste autodestruibles: 





Y hups://www.bo.gov/index?s=opportunitykmode=formétid=880ecdf17 
0660730fe0fb8745fSc2bec&tab=core&tabmode=list&= 


El interés en este tipo de dispositivos se anuncia públicamente en el sitio 
oficial de DARPA en 2013, que se puede consultar en el siguiente enlace: 


4 htp://owwdarpa.mil/NewsEvents/Releases/2013/01/28.a5px 


1.2 MOTIVACIÓN 





Evidentemente la principal motivación de la ingeniería inversa es obtener 
el conocimiento suficiente sobre un producto final como para poder reproducir de 
manera total o parcial el objeto analizado de la manera más fiel posible, El objetivo 
соп е1 que esto se pretende puede ser muy diverso. 


En entornos militares es común llevar a cabo labores de ingenieria inversa 
para estudiar la tecnología del enemigo o fuerzas alternativas. Esto permite situarse 
al mismo nivel o incluso por delante, pudiendo prevenirse de dichas tecnologías, e 
incluso estar por delante mejorando la tecnología y/o detectando fallos en la misma 
рага usarlo contra los propios desarrolladores de esa tecnología. Un caso conocido 
históricamente y comentado anteriormente, es el de la máquina Enigma utilizada 
en la Segunda Guerra Mundial para cifrar los mensajes de los alemanes, y cuyo 
algoritmo de cifrado fue roto mediante técnicas de criptoanálisis e ingeniería inversa 
por los Estados Unidos. 
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Sin embargo, para lo que nos ocupa, cl caso de la ingenieria inversa aplicada 
al software, hay también variedad sobre los motivos que llevan a realizar este tipo de 
prácticas sobre un software concreto. 


1.2.1 Descifrar algoritmos y/o especificaciones privadas 


Uno de los usos más comunes y comentados anteriormente es el caso de 
descifrar un algoritmo criptográfico para interceptar mensajes privados y poder así 
obtener ventaja estratégica. 


También hay gran interés en el mundo industrial para acceder a los detalles 
de implementación de algoritmos matemåticos, para la realización de cálculos 
complejos que conlleven una investigación importante. Este puede ser el caso de 
programas destinados al cálculo de estructuras físicas, bioingenicría, química, etc. 
Si es posible acceder al software capaz de realizar dichos cálculos, ese software 
es susceptible de ser analizado desde el punto de vista de la ingeniería inversa, 
para extraer el conocimiento implementado cn forma de software, Esto ayuda a la 
competencia a conocer vías de investigación, o incluso ahorrar el tiempo necesario 
para llegar al estado de perfección de dicho software y poder comercializar otro 
producto similar o incluso mejorado en algunos aspectos. 


Centrándonos en entornos informáticos de infraestructuras, podemos dirigir 
estas técnicas al descifrado de protocolos de comunicación y formatos de fichero. 
Un caso bien conocido sobre aplicación de ingeniería inversa a protocolos de 
comunicación se dio en el protocolo de archivos compartidos diseñado por Microsoft, 
antiguamente llamado SMB (Server Message Block) y actualmente renombrado a 
CIFS. Estas tareas realizadas de ingenieria inversa, tanto a nivel de análisis estático de 
código, como análisis dinámico, donde se analizaba el tráfico resultante, concluyeron 
con la implementación de un programa denominado SAMBA, desarrollado bajo 
licencia código abierto que permitía llevar a cabo todas las funcionalidades de SMB. 


Respecto a los formatos de fichero, es especialmente conocido el caso del 
proyecto OpenOffice, que llevó a cabo tareas de ingenieria inversa para poder descifrar 
los formatos de fichero de la suite ofimática Microsoft Office. Estas investigaciones 
dieron lugar no solo a la aparición de una nueva suite ofimática compatible con la 
suite ofimática más importante del momento, sino que aportó un nuevo formato de 
ficheros abierto, que más tarde Microsoft adoptó en parte para el desarrollo de sus 
nuevas generaciones de formato de ficheros ofimåticos. 


22 REVERSING. INGENIERÍA INVERSA ORAMA 





1.2.2 Agregar funcionalidades 


Una vez que un software ha sido desarrollado completamente, se llevan a 
cabo las labores de mantenimiento y/o implementación de nuevas funcionalidades 
requeridas, tal y como se ha mostrado anteriormente en el ejemplo del Modelo 
Unificado de Desarrollo de Sofiware. Estas labores de mantenimiento y desarrollo 
cubren las necesidades de un sofíware desplegado en entornos de producción. 





Los entornos informáticos son extremadamente dinámicos y los cambios 
se suceden con gran frecuencia. Esto conlleva cambios de sistemas operativos, 
hardware, politicas de uso, legislación, requerimientos de negocio, cambio en las 
costumbres del usuario, adaptación a nuevos procedimientos de trabajo, etc. 


Cuando una empresa o grupo de usuarios individuales comienzan a utilizar un 
sofware determinado, es porque sus necesidades se alinean perfectamente a la linea 
de trabajo y desarrollo del producto. Esto hace que se deleguen las competencias de 
la empresa o usuarios hacia el software en cuestión dentro del ámbito para el que está 
diseñado. Esto va creando una fuerte dependencia de los usuarios hacia el producto. 


Mientras el producto no varíe su enfoque y sepa adaptarse a los cambios € 
incluso adelantarse a ellos, no surge ningún problema y la convivencia es factible 
y beneficiosa. Sin embargo, es muy fácil y común que esta convivencia se rompa 
por algún motivo. Es posible que el producto no se desarrolle a la velocidad 
esperada/necesaria de los usuarios; que el producto no sepa hacia dónde avanzar y 
el desarrollo quede estancado en simples correcciones de errores; que un usuario en 
cuestión dominante imponga la evolución del producto conforme a sus necesidades 
y que no estén alincadas con el resto de usuarios; que por motivos de cuotas de 
mercado, el producto quiera ser generalista y así abarcar más usuarios, perdiendo 
las características concretas que lo hacían especial para sectores más pequeños de 
usuarios; falta de previsión en el dimensionamiento de los recursos y que puedan 
responder a tiempo y en forma con las necesidades que surjan del desarrollo normal 
del software; o simplemente que la empresa que desarrolla el software, decida 
abandonar el producto o directamente la empresa deba cerrar y el desarrollo del 
sofware se paralice definitivamente. 





Uno solo de estos motivos es suficiente para que un usuario decida analizar 
en profundidad el sofiware en cuestión para tratar de mejorar/ampliar el sofiware en 
sî, adaptándolo a sus necesidades particulares o específicas a un grupo determinado 
de usuarios. Para llevar a cabo cualquier modificación es necesario realizar tareas de 
ingeniería inversa, y poder así retomar el desarrollo o enlazar con lo existente. 
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Lo que sucedió con Gnutella, es un ejemplo de lo comentado anteriormente. 
El actual protocolo de compartición de ficheros mediante una red descentralizada 
(Peer-to-peer, P2P), conocido como Gnutella y que recibe el nombre del primer cliente 
para esa red denominados con el mismo nombre, vivió un episodio relacionado con 
lo comentado hasta ahora, 


El primer cliente de la red Gnutella y por el que la red adoptó ese nombre, 
fue desarrollado por Nullsoft a principios de 2000. Recientemente, ha sido adquirido 
por AOL. El 14 de marzo el programa se puso a disposición para su descarga en los 
servidores de Nullsoft. La noticia fue publicada anticipadamente en Internet y se 
produjeron miles de descargas del programa esc mismo día. El código fuente iba a 
ser liberado más tarde, bajo la Licencia Pública General de GNU (GPL), sin embargo 
los desarrolladores originales nunca tuvieron la oportunidad de lograr este propósito, 
ya que al día siguiente AOL detuvo la disponibilidad del programa debido a aspectos 
legales e impidió a Nullsoft seguir trabajando en el proyecto. Pero la expectación y 
la aceptación del cliente había sido tal que poco días después de su cancelación el 
protocolo había sido objeto de labores de ingenieria inversa, y los clones de código 
libre y de código abierto compatible con el original comenzaron a aparecer, 


Esto es una muestra de cómo es posible continuar un proyecto dado por 
finalizado, o retirado del mercado por diversos aspectos, si se tiene el suficiente 
interés al respecto. 


1.2.3 Validación y verificación del software 


Algo que a menudo se sobreentiende acerca del software y que no siempre 
sucede, es que haga exactamente las acciones para las que se diseñó de manera 
formal. Es decir que el sofware sea correcto en toda su implementación. Si esto 
sucede el software se da por correcto y se dice que el sofiware está validado. La 
validación del software es un proceso de control que asegura que el software cumple 
con su especificación y con los requerimientos y necesidades del usuario. 


Para poder validar un software se llevan a cabo evaluaciones de todo 
el sistema o de alguno de sus módulos o componentes. Cuando se realizan estas 
evaluaciones se dice que se está llevando a cabo la verificación del software. 


La ingenicría inversa se utiliza para comprobar que hace lo que debe, que 
se cumplan las especificaciones y que no haga cosas que no debe. En este caso van 
incluidos las puertas traseras (backdoors), vulnerabilidades, funcionalidades de pago 
ocultas, ete. 
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Un caso de puertas traseras, se dio en el famoso software de HP, donde se 
descubrió que se podia acceder a través de SSH utilizando la contraseña “HPSupport”. 
en un sofiware con un precio de más de 10.000€. 


Y hup://news.slashdot.org/story/13/07/11/2349201/hp-keeps-installing- 
secret-backdoors-in-enterprise-storage 


Con este tipo de casos se hace patente la necesidad de llevar a cabo labores 
-nicría inversa por parte de cualquier 





de auditoria de software apoyándose en la 


1.2.4 Detección de vulnerabilidades 


Además de la det 
otros tipos de puertas traseras, es también importante poder detectar vulnerabilidades 





сіб de funcionalidades ocultas, contraseñas secretas u 





de software mediante las cuales se puede llegar a comprometer los sistemas afectados, 


y quedar bajo el control de cualquier atacante que lo explote satisfactoriamente. 


Es habitual llevar a cabo auditorías de código fuente en los distintos software. 
»„ debido a 
fuente no sea vulnerable si se compila 
en otra arquitectura. O 
que simplemente sobre código fuente no lo sa, pero tras llevar a cabo algún tipo de 


sobre lodo en los destinados a servidores o sistemas criticos. Sin emb; 





varios factores, puede suceder que un códig 








para una arquitectura, mientras que sí puede ser vulnerable 


optimización de código, se introduzcan vulnerabilidades al dar por supuesto algún 
tipo de comprobación o al eliminar código considerado inactivo, pero que en la 
práctica sea imprescindible para evitar la explotación de una vulnerabilidad. 


Gogul Balakrishnan, en su tesis doctoral: 
Y htip:l/research,es.wisc.edulwpis/papers/balakrishnan_thesis pdf 


Introdujo el término WYSINWYX (What You See Is Not What You eXecute) 
rabilidades introducidas por los compiladores que no 
jente porción de código en 


como resultado de las vul 





pueden ser detectadas en el código fuente. Tómese la 





C a modo de ejemplo para explicar el concepto: 
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En el código fuente no se aprecia ninguna vulnerabilidad, sin embargo al 
compilar dicho código fuente, el compilador aplica una optimización de eliminación 
de código redundante, donde se elimina el bloque if, ya que si fun nunca debe ser 
NULL, comprobar si tun es NULL sería redundante y lo elimina. Sin embargo, si 
sucede un error en _tun_get(fle) y se retoma NULL, dicha eliminación permite 
continuar la ejecución con fun apuntando a NULL, lo que permite un ataque de 
“NULL reference pointer”. 


1.2.5 Análisis de malware 


Uno de los usos comerciales más utilizados (y cada vez más), es el uso 
de ingeniería inversa para el análisis de malware. Cada día aparecen millones de 
muestras únicas en Internet. Muchas de estas muestras son mutaciones o variaciones 
de estructuras de malware comunes. Analizar en profundidad el malware es 
importante para conocer, no solo qué acciones está llevando a cabo, sino para poder 
detectar a las potenciales víctimas, por ejemplo clientes de un determinado banco, 
así como la infraestructura utilizada, centros de control de máquinas infectadas, y de 
esta manera poder neutralizar la amenaza. 





Por este motivo, un malware no suele resultar sencillo de comprender, no 
suele llevar símbolos de depuración, aunque algunos hay que sí, no es lo habitual. 
Tampoco suelen ser cómodos de analizar. Este tipo de software suele implementar 
técnicas que dificultan la utilización de herramientas de depuración o desensamblado 
automático, conocidos como anti-debuggers, que pretenden explotar defectos de 
las herramientas para provocar errores o situaciones erróneas y dar información 
incorrecta. O, directamente, detectar su propia ejecución en este tipo de entornos y 
realizar acciones no fraudulentas para hacerse pasar por un sofware normal en lugar 
de malware, y de esta forma no delatar la infracstructura con la que se comunica. 





También suelen ir empaquetados, de tal forma que una vez se ejecutan, si 
consideran que el entorno es real y no un laboratorio de análisis o herramientas de 
depuración, ejecuta los procedimientos de autodescompresión, descifrando el código 
¡oso real y ejecutándolo una vez descifrado. 








El sector del malware está continuamente en movimiento debido a lo 
rentable que resulta a los ciberdelincuentes, y es por esto que no vale solo con 
saber utilizar herramientas automatizadas, sino que es necesario tener una buena 
base y fundamentos en cuanto a construcción y reconstrucción de código para poder 
afrontar los distintos retos que se presentan. 
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1.3 LIMITACIONES 





La ingenieria inversa es una disciplina cuyos resultados son altamente 
satisfactorios, y permiten “decompilar” exitosamente, ya sea de manera automática 
o manual, la mayoría de los binarios que se propongan. Es por esto que se han podido 
implementar clientes a protocolos de comunicaciones o analizadores de formatos de 
fichero de manera completa y eficaz, así como se puede conocer los detalles internos 
de cualquier malware. 


Sin embargo, no esun camino de rosas. Una vez se lleva a cabo la compilación 
del código fuente, se pierde parte de la información importante para comprender el 
porqué de ciertas partes de código. Es el caso de los comentarios. El código fuente 
Suele estar repleto de comentarios del programador, de forma que resulta útil para 
cualquiera que tenga que entender o modificar el código fuente, o para el mismo 
programador pasado un tiempo sin estar en contacto con ese código. Como se podrá 
ver más adelante en la Hlustración 3 un código fuente con comentarios y nombres 
descriptivos para las variables, mientras que en la Hustración 4, sin embargo, no 
queda ni rastro de ningún tipo de comentario del programador. 


Respecto a los nombres de las variables y funciones, es posible mantener 
dicha información denominada “símbolos de depuración” que, como bien dice su 
nombre, son utilizados para tareas de depuración a nivel de código binario, incluso 
es posible almacenar la relación entre el código fuente y cl código binario, pero el 
código fuente en sí no se almacena dentro del binario. 


Los símbolos de depuración aportan gran ayuda a la hora de realizar tareas 
de ingeniería inversa, sin embargo, compilar un binario con simbolos de depuración 
implica un coste en espacio que normalmente no se suele querer asumir. La razón 
suele ser de tres a cinco veces más espacio para el código binario con simbolos 
frente al binario sin símbolos. Además, si el programa es de código cerrado, los 
desarrolladores no suelen querer aportar dicha información, y más aún siendo tan 
costoso en cuanto a espacio. Aunque se suele dar el caso de que los desarrolladores 
utilicen los simbolos para uso intemo de depuración, y compilen finalmente una 
versión de liberación al público en la que se eliminen dichos símbolos. 


Por otro lado, debido a la optimización de código, el múmero y tamaño de 
las variables puede verse ligeramente modificado, tal y como se verá en el siguiente 
capítulo. Estas optimizaciones de código modifican el código objeto para aumentar 
1а eficiencia del mismo al ejecutarse. Estas modificaciones dificultan las tareas de 
reconstrucción de código al no poder invertir el proceso de generación de código 
fuente a código objeto tal cual. A modo de ejemplo, se procede a analizar cl siguiente 
código fuente en C: 








slo 1 INTRODUCCIÓN A LA INGENIERÍA INVERSA. 








Se lleva a cabo un proceso automático de decompilación con la famosa 
herramienta de decompilación Hex-Rays, un plugín para el famoso desensamblador 


IDA Pro: 





Como se puede observar, y a pesar de trat 






se de un programa pequeño y 


sencillo, en su reconstrucción de código sí mantiene una estructura básica similar al 





original, pero desaparece totalmente la información sobre las variables. Es el caso 


de mp y retval. 





Las variables son etiquetas a porciones de memoria que el programador 
establece para poder acceder a dichas porciones de memoria de manera fácil y 
abstracta. Sin embargo, en el código binario el compilador puede acceder a una 


variable, simplemente desplazándose a través de otra variable anterior que utiliza 





como base, por lo que en lu; 





de dos variables, se ve uno, y operaciones aritmi 











sobre su dirección para acceder a esta segunda. Es por ello que la reconstrucción de 
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variables es un tema complejo y basado en el uso del código sobre las direcciones 
de memoria. 


Otra limitación importante es la referente a la ofuscación y códigos 
automodificables. Este tipo de códigos son propios de malware o programas 
comerciales de pago, para los que no se quiere que se lleve a cabo ingenieria inversa 
con ánimo de vulnerar su sistema de protección por licencia de pago, y se utilice 
sin llevar a cabo el pago correspondiente de licencia. Lo que suele conocerse como 
“crackear” un software. En el caso del malware se realiza para evitar las detecciones 
“automáticas por parte de los antivirus y sandbar, sistemas aislados donde se lanza el 
malware para ser infectados y analizar su comportamiento. 





Este tipo de mecanismos, consta de varias partes, pero básicamente lo que 
hacen es ejecutar una primera rutina de descifrado del contenido real, almacenado en 
una zona del fichero binario, y una vez se ha acabado de descifrar dicho contenido, se 
le pasa el control al código real. Un ejemplo muy conocido y sencillo es el conocido 
compresor UPX. 


1.4 ASPECTOS LEGALES 





La ingenieria inversa provoca mucha controversia en cuanto a su legalidad. 
Si bien la realización de ingeniería inversa para la detección de vulnerabilidades, 
© para comprender como funciona un software y hacerlo compatible con otro, son 
motivaciones claramente positivas para el software analizado, hay otras acciones, 
como la obtención del código fuente para ofrecer un producto igual o similar por 
parte de otra empresa, que son las más perseguidas por la ley. Estas sin duda son 
las que claramente buscan copiar el software original incumpliendo las leyes de 
propiedad intelectual. 


Aunque hay diversas leyes según los diferentes paises, en gran medida todas 
aportan un mismo enfoque basado cn la finalidad con la que se llevan a cabo estas 
técnicas. Si nos centramos en España, podemos ver que los aspectos legales están 
recogidos еп: 


Y hitp:/moticias juridicas.com/base_datos/Admin/rdleg1-1996.1117.html 


Respecto al análisis del software en cuestión, el artículo 100.3 establece 
que: 
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Art. 100.3 LPI: “El usuario legítimo de la copia de un programa estará 
facultado para observar, estudiar o verificar su funcionamiento, sin autorización 
previa del titular, con el fin de determinar las ideas y principios implícitos en 
cualquier elemento del programa, siempre que lo haga durante cualquiera de las 
operaciones de carga, visualización, ejecución, transmisión o almacenamiento del 
programa que tiene derecho a hacer”. 





Lo que deja de manifiesto que un usuario legítimo, que haya adquirido la 
licencia de uso de manera legal, tiene permitido la realización de análisis del software 
para comprender su funcionamiento, donde se incluyen tareas de ingenieria inversa. 


Respecto a las empresas que deseen llevar a cabo labores de ingenieria 
inversa, según los artículos 100.5, 100.6 y 100.7, estos podrán llevarlas a cabo si 
es indispensable para obtener información que permita la interoperabilidad con otro 
sofware. Y siempre y cuando se cumplan los siguientes requisitos: 





FF Que tales actos sean realizados por el usuario legítimo o por cualquier 
otra persona facultada para utilizar una copia del programa, o, en su 
nombre, por parte de una persona debidamente autorizada. 


Que la información necesaria para conseguir la interoperabilidad no haya 
sido puesta previamente y de manera fácil y rápida, a disposición de las 
personas a que se refiere el párrafo anterior. 


F Que dichos actos se limiten a aquellas partes del programa original que 
resulten necesarias para conseguir la interoperabilidad. 


F Que la información obtenida se utilice únicamente para conseguir la 
interoperabilidad del programa creado de forma independiente. 


F Que la información obtenida solo se comunique a terceros cuando 
sea necesario para la interoperabilidad del programa creado de forma 
independiente. 


F Que la información obtenida no se utilice рага el desarrollo, producción 
o comercialización de un programa sustancialmente similar en su 
expresión, o para cualquier otro acto que infrinja los derechos de autor. 


No obstante, antes de llevar a cabo tareas de ingenieria inversa con finalidades 
distintas a las aquí indicadas, se recomienda consultar con un experto en legislación 
relacionada con estos aspectos. 
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1.5 CUESTIONES RESUELTAS 





1.5.1 Enunciados 


1. ¿Es legal la realización de ingenieria inversa en España?: 
a. Si 
b. No 
e. Depende de la finalidad con la que se realiza 


2. ¿Qué articulo del Real Decreto Legislativo 1/1996, de 12 de abril, 
establece que el usuario legítimo de una copia de un programa de 
ordenador puede analizar o estudiar su funcionamiento, aun sin contar 
con la autorización expresa del titular de dicho programa, siempre que lo 
haga durante la normal ejecución del mismo?: 

1007 

100.6 

100.5 

100.4 

1003 


3. ¿Qué artículo o artículos del Real Decreto Legislativo 1/1996, de 12 de 
abril, establece las condiciones con las que las empresas pueden llevar a 
cabo ingeniería inversa sobre un sofhvare concreto? 

а. 1007 
b. 100.6 
с. 100.5 
4. 1004 
e. 100.3 


4. ¿Son aplicables los artículos del Real Decreto Legislativo 1/1996, de 12 
de abril, en otros países de la Unión Europea?: 
a Si 
b. No 
e. Depende de la finalidad con la que se realiza 
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i. ¿Son aplicables los artículos del Real Decreto Legislativo 1/1996, de 12 
de abril, en Estados Unidos? 


a Si 
b. No 
e. Depende de la finalidad con la que se realiza 
6. ¿Es posible obtener el código fuente original partiendo de los ficheros 
binarios, tal y como lo escribió el desarrollador o desarrolladores?: 


a. Si 


b. No 
Depende de las opciones de compilación 


8 с. 
5 

& 7. ¿Cuál de las siguientes no es una motivación para llevar a cabo ingeniería 
8 inversa sobre un sofiware?: 

> 

© a. Búsqueda de vulnerabilidades. 

Е b. Obtención de detalles de implementación para operar con otros 
Š softwares. 

E ©. Conocer el comportamiento de un software sospechoso de ser 


Е 
5 e 
а malware. 
© d. Obtención de los comentarios del desarrollador para obtener 
Ё información detallada. 
8 
g 8. ¿Es posible invertir el proceso de compilación de manera literal?: 
o a Si 
3 b. No 
e. Depende de las opciones del compilador 
). ¿Las labores de ingenieria inversa, som acciones perfectamente 
sutomatizables y con resultados 100% fiables?: 
a. Depende de las opciones del compilador 
b. Si 
с. № 
10.¿Es aplicable el concepto de ingenicria inversa exclusivamente al 
desarrollo de sofíware?: 


a. No 
b. Si 
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1.5.2 Soluciones 


10.a 








COMPILADORES 


Introducción 


Esta unidad se centra de lleno en la disciplina de los compiladores. Qué 
son, cómo funcionan, las fases por las que pasa para llevar a cabo sus tareas y de 
qué manera es útil conocer estos detalles para invertir el proceso y convertir código 
fuente a partir del código objeto. 


Objetivos 


Cuando el alumno haya finalizado la unidad didáctica, será capaz de identificar 
y comprender el funcionamiento de cada una de las fases de un compilador, Será 
capaz de implementar analizadores de diferentes tipos para poder analizar cualquier 
lenguaje dese el punto de vista de un compilador. Además de experimentar por sí 
mismo el proceso de conversión de código fuente a código objeto. 


2.1 TEORÍA DE COMPILADORES 








“A grandes rasgos, un compilador es un programa que lee un programa 
escrito en un lenguaje, el lenguaje fuente, y lo traduce a un programa equivalente 
en otro lenguaje, el lenguaje objeto. Como parte importante de este proceso de 
traducción, el compilador informa a su usuario de la presencia de errores en el 
programa fuente” 
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Programa Programa 
fuente —» | compilador => objeto 














Mensajes de error 


Esta es la definición ofrecida por el libro de referencia en temas de 
compiladores. En su versión en castellano: 


Aho, Alfred V Ravi Sethi, Jeffrey D. Ultman (2008). Introducción a la 
Compilación. Compiladores: Principios, técnicas y prácticas. México: Addison 
Wesley. 





También conocido por Dragon book por su primera llamativa portada: 
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Y las siguientes en versiones actualizadas: 


Alfred VU Aho 
O 
Jeffrey D. Ullman 





lostración 1. Red Dragon 





lustración 2. Purple Dragon 
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Donde el dragón tiene escrito “Complexity of Compiler Construction” y el 
caballero con armadura empuña una lanza con el texto “LALR parser generator”. 





La portada ya muestra la gran batalla llevada a cabo por los autores para 
lidiar con este campo de la ingenicría tan complejo. Muestra de ello son los inicios 
de los compiladores. En 1954 se empezó a desarrollar un lenguaje que permitía 
escribir fórmulas matemáticas de manera traducible por un ordenador; le llamaron 
FORTRAN (FORmulae TRANslator). Fue el primer lenguaje de alto nivel y se 
introdujo en 1957 para el uso de la computadora IBM modelo 704. 


Surgió asi por primera vez el concepto de un traductor como un programa 
que traducía un lenguaje a otro lenguaje. En el caso particular de que el lenguaje a 
traducir es un lenguaje de alto nivel y el lenguaje traducido de bajo nivel, se emplea 
el término compilador. 


La tarea de realizar un compilador no fue fácil. El primer compilador de 
FORTRAN tardó 18 años еп desarrollarse. Esto deja de manifiesto la cantidad de 
investigación que se necesitó realizar para poder llegar a un producto final como fue 
un compilador completo, por sencillo que fuera su lenguaje. Toda esta investigación 
aportó la gran parte de teoría, técnicas y herramientas utilizadas hoy día en los 
campos de lenguajes y autómatas. 


Los compiladores permiten escribir código fuente en lenguajes de alto nivel, 
es decir, en lenguajes no dependientes de la arquitectura del ordenador en el que 
se ejecute, así como permitir que el lenguaje sea Fácilmente interpretable por un 
ser humano, lejos de ser una lista de comandos secuenciales como venía siendo el 
lenguaje ensamblador u otros lenguajes de bajo nivel. 


Los lenguajes de alto nivel han permitido un desarrollo exponencial de 
software que se adapta a las necesidades de los usuarios y funcionan sin prácticamente 
cambios en diferentes arquitecturas y tipos de ordenadores. Esta ventaja junto con 
tras ventajas, como la reutilización de código, y disciplinas como la ingeniería de 
software, nos han llevado a los complejos programas informáticos con entornos 
visuales de escritorio, así como efectos gráficos y videojuegos en 3D en tiempo real, 
el desarrollo de complejos sistemas de comunicaciones que llevaron a la creación 
y utilización en masa de Intemet o la capacidad de llevar a cabo software con 
finalidades matemáticas, médicas u otros sectores, y nos permiten realizar grandes 
obras de ingenieria, bioingeniería, química o análisis y diagnósticos médicos, como 
muchas otras utilidades del software. 


Las siguientes imágenes muestran las diferencias entre un lenguaje de alto 
nivel, código ensamblador y el fichero binario final directamente interpretable por el 
procesador del ordenador: 





COMPILADORES 








Programa fuente 








Mustraciön 3. Códi 





Este código escrito en un lenguaje de alto nivel, en concreto C. Realiza una 
tarea muy sencilla: analizar el primer argumento introducido por el usuario por línea 


de comandos y mostrar un mensaje concreto según el caso, o salir con un mensaje de 








error si no hubiera argumento. 








Como se puede observar en la im: 





en, este código de alto nivel, permite 
no solo la utilización de variables con nombre a la libre elección del programador, 
o así como la indentación del texto. 





sino la utilización de comentarios sobre el códi 








Estas características facilitan la lectura a las personas, aunque no tenga ninguna 


trascendencia respecto al código máquina a generar. 


También se pueden observar la utilización de estructuras de código, como 
o y ayudan a la 





pueden ser las funciones, que ayudan a la reutilización de códi; 
abstracción de código, pudiendo construir código centrándose en lo particular, para 


ir resolviendo problemas más generales, además de poder realizar invocaciones 





recursivas sin necesidad de llevar el control de manera explicita 


Estas facilidades y proximidad del código fuente al lenguaje natural 





permiten al desarrollador centrarse en 






'el qué” debe hacer el sofware en lugar de en 


“el cómo” debe implementarlo para que funcione 





en esa máquina en arquitectura u 
ordenador en concreto. 


Programa objeto 


sido 
generar un código objeto correcto y operativo, se convierte en un código objeto, por 





Una vez que el compilador ha desarrollado todas las etapas y conseg 








en muestra el código ensamblador, 





¡ente im 








que compone el programa objeto, derivado del código fuente, mostrado anteriormente 
en la Mustración 3 
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n sintavis Intel 
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Esta imagen muestra código ensamblador totalmente operativo y convertible 
aun programa binario final. Antes de crear los primeros compiladores, se programaba 
únicamente de esta manera en el mejor de los casos. Como se puede observar, cada 
linea contiene una única instrucción, y se compone de: 


F Un elemento: (Mnemónico) 


F Dos elementos: (Mnemónico y Operando!) 


F O tres elementos: (Mneménico, Operando] y Operando2) 


MC TAS ME 


Los mnemónicos son palabras que sustituyen a códigos de operación. 
Esto permite emplear RETO en lugar de tener que escribir directamente el valor 
hexadecimal 0xC3. Esta traducción de códigos de operación por palabras es lo que 
denominamos código ensamblador. El código ensamblador se puede escribir con 
diferentes sintaxis. En el ejemplo anterior se utilizó sintaxis Intel, pero existen otras, 





por ejemplo AT&T. La siguiente imagen muestra el mismo código ensamblador del 
código fuente en C pero con sintaxis AT&T: 
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Como se puede apreciar hay varias diferencias en cuanto a los mnemónicos 
y operandos, tal y como se puede veren 
sintaxis: 





¡cción expresada en ambas 


F Intel 
ORD PR [op 16 si | 

F ATAT 

E 


Además de las instrucciones, se puede observar cómo hay etiquetas dentro 
del código, a modo de localizacio: 





jes que se utilizan para las bifurcaciones de código 





Estas etiquetas son traducidas por direcciones de memoria relativas en la 
fase de construcción del binario final. 





Programa binario ejecutable 





Una vez que el có 





objeto ha sido generado, entra en juego otras 
herramientas fuera del alcance del compilador, como son el ensamblador y el 


enlazador de códigos objetos. 
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El ensamblador gencra código binario partiendo del programa en 


di 


lenguaje ensamblador. Es decir, tra 





¡ce los mnemónicos en los códigos binarios 





correspondientes. 


Porotro lado, el enlazador de códigos objeto se encarga de obtener los códigos 
jas disponibles. Una 


jecutable, o en forma 





objeto requeridos por el código objeto en cuestión de las libre 








todas las piezas necesarias, genera un fichero final 
de librería del sistema. 


Si nos fijamos en el programa objeto de la ustración 4, podemos observar 


cómo se hace referencia a funciones no contenidas en el código ensamblador 





resultante: 





Ilustración 6. Cdi 
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Estas referencias externas deben ser resueltas y localizadas de alguna forma 
para que cuando el procesador ejecute el salto а |; 
debe hacerlo. Este probl 
dentro del ejecutable final, que contiene las funciones ex 


función externa, sepa a dónde 








jelve el enlazador, introduciendo una sección 





mas requeridas por el 
ejecutable: 








requiere de funci 





Ilustración . Ejec 





Y donde cl enlazador dinámico almacenará la dirección exacta de esa función 





almacenada en una librería dinámica, o introducirá el código completo de la función 






en el ejecutable si se decide que la función, en lugar de ser invocada de manera 





dinámica, se haga de manera estática. 





Este esquema, permite que el mismo programa binario final, sea ejecutado en 


diferentes ordenadores cuyas librerias hayan sido cargadas en direcciones aleatorias 





o en orden dife 





2.2 FASES DE UN COMPILADOR 


Conceptualmente un compilador opera en fases. Cada una de estas fases 





transforma el programa fuente de una representación en otra. En la práctica algunas 





fases se pueden agrupar y las representaciones intermedias entre las fases no necesitan 


ser construidas explícitamente. La muestra estas fases: 








ORAMA 
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Como se puede observar, el administrador de la tabla de simbolos es global a 
todas las fases e interactúa de forma dinámica en cada una de ellas. Esto permite que 
se puedan realizar acciones sobre los símbolos en diferentes fases sin que se pierda 


el significado ni el contexto de los mismos. Este administrador asocia atributos a 
adores, y esto es esencial para conocer el espacio a reservar 





cada uno de los identi 
a cada identificador, el tipo del mismo y su ámbito de utilización dentro del contexto 
s posible determinar el número 





del programa. Para los identificadores de funcione: 
y tipo de argumentos, así como el método para pasar cada argumer 





úficador, pero no cs 





Toda esta información se almacena en una tabla de símbolos. Durante el 


análisis léxico es posible determinar el nombre de cada ider 
hasta la fase de análisis sintáctico, donde sc puede introducir en la tabla cl tipo del 


identificador, Por ejemplo, para la siguiente línea de código en C 





El identificador “structPropia” no puede almacenar el espacio total hasta 
el análisis sintáctico. Durante el análisis léxico, se van analizando los tokens o 


palabras clave de forma secuencial es por esto que una vez ha finalizado de analizar 
la estructura no vuelve atrás para almacenar los atributos de este, sino que se hace 


en las siguientes fases. 
obal a todas las fases € interactúa 





El manejador de errores, también es 
con todas ellas de forma dinámica. Cada fase puede encontrar errores, sin embargo, 


después de detectar cada error, cada fase debe de tratar de alguna forma ese error, 
ndo la detección de más errores en 


para poder continuar la compilación, permiti 
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el programa fuente. Pueden haber errores críticos que impidan continuar con la 


compilación, como pueden ser los errores que incumplan con las estructuras léxicas 





(introducción de tokens no esperados) o sintácticas (la introducción de identificadores 





no declarados). Nót 





la diferencia de que en la fase de análisis léxico, los 
identificadores no declarados no provoc: 





error, ya que simplemente se 
limita a asociar cada parte del 





texto con un token en concreto, basado en una palabra 
reservada o expresión regular. Es por esto que un identil 
identificado por una expresión re 
bar 


gramática, ya que el tipo de datos es requerido. 


ador no declarado es 








ular que identifica variables y no provoca ningún 





en la fase de análisis sintáctico no es capaz de asociarlo con una 


Para ver de una manera más directa y explicativa estas diferentes fases, a 
continuación se muestra en la Hlustración 8 la traducción de una proposición de 
código fuente a código objeto: 





El compilador va pasando por las diferentes fases, modificando el código 


fuente de una representación a otra en cada fase. 
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23 ANÁLISIS LÉXICO 








El analizador léxico es la primera fase que lleva a cabo el compilador. Su 
labor es analizar el código fuente y elaborar una lista de componentes léxicos que 
utilizará el analizador sintáctico en su análisis. La forma habitual de colaboración 
suele ser la de crear una función o conjunto de ellas, que utiliza el analizador 
sintáctico para solicitar el siguiente componente léxico. De esta forma, el analizador 
sintáctico va analizando cada componente léxico y realiza las acciones necesarias, 
como insertar un identificador en la tabla de simbolos, generar algún error si incumple 
con la estructura sintáctica u otras labores. Una vez que las funciones para obtener el 
siguiente componente léxico no puedan obtener más componente léxicos, se habrá 
llegado al final de la fase de análisis léxico. 








Un analizador léxico es capaz de llevar a cabo todo el proceso de manera 
lineal, en una sola pasada, no necesita de recursión para procesar el código fuente, 


23.1 Definición de términos 


Para analizar de manera léxica un código fuente se manejan varios términos 
con descripciones y usos muy concretos: 


F Componente léxico o token 
Un componente léxico o token, es un conjunto de cadenas en la entrada 
para las cuáles se produce como salida un mismo componente léxico. 
Este conjunto de cadenas se describe mediante una regla llamada patrón. 
Se dice que el patrón concuerda (match) con cada cadena del conjunto. 


F Patrones 
Son una serie de reglas que deciden si un conjunto de cadenas de entrada 
cumplen o no con esa especificación. Estas reglas se implementan en 
forma de AFD (Autómatas Finitos Deterministas). Este autómata se 
representa en forma de diagrama de estados, de tal forma que si la cadena 
de entrada es capaz de llegar al estado final, se dice que dicha cadena es 
aceptada por el autómata y cumpliría con el patrón. Estos patrones son 
tratados como expresiones regulares de tal forma que es posible detectar 
cada token comprobando si cumple o no con determinadas expresiones 
regulares. 


Y Lexemas 


Un lexema es una secuencia de caracteres en el programa fuente con la 
que concuerda el patrón para un componente léxico. 
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Para una mejor comprensión de los términos anteriormente descritos, vamos 
a mostrar varios ejemplos prácticos 


Componente 
o token 








и if if 
switch swich switch 

relación LARA > 
ia velocidad, varl, PI Letra seguida de letras y digitos 
entero 31416,0,2 


literal “cadena de texto”. 





En la tabla anterior, se muestran varios token para los que el lexema 
concuerda con el patrón. Dicho patrón se ha definido de una manera informal para 
su mayor comprensión. No obstante, y para una mayor claridad a continuación se 
proceden a definir en forma de expresión 





gular el patrón para el cual un lexema 
concuerda o no con un token: 





Componente L 





Patrón en forma de expresión 


o Token чы regular 
и if и 
switch swich switch 
relación < o> [ooie] 
“ velocidad, varl, PI [2-2A-Z][a-2A-Z0-9]* 
entero 31416,0,2 КЕН 
шеги “cadena de texto” ur 


Cuando más de un patrón concuerda con un lexema, el analizador léxico 
debe proporcionar información adicional sobre el lexema concreto que concordó 
con las siguientes fases del compilador. El analizador léxico recoge información 
sobre los componentes léxicos en sus atributos asociados. Los componentes léxicos 
influyen en las decisiones del análisis sintáctico, y los atributos, en la traducción de 
los componentes léxicos. En la práctica los componentes léxicos suelen tener un 
solo atributo, un apuntador a la entrada de la tabla de símbolos donde se guarda la 
información sobre el componente léxico. 


Es importante también analizar un poco los errores léxicos, que aunque son 
pocos los que se pueden detectar en esta fase debido a la visión tan restringida del 
código fuente, no solo son susceptible de producirse, sino que se pueden llevar a 
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cabo diferentes estrategias para tratar de recuperarse de ellos sin tener que forzar a la 
finalización de proceso de compilación. 


El analizador léxico no es capaz de detectar ningún fallo al analizar la palabra 
wile en la siguiente porción de código en C 


Un analizador léxico no puede detectar si wile es un error de escritura, donde 
se quiso decir while o un identificador de función no declarado. 


Si en este punto se produce algún error, se puede tratar de recuperar 
aplicando algún algoritmo de recuperación de errores. Dado el caso de que ningún 
patrón concuerde con el prefijo de la entrada actual, se puede tratar de eliminar 
los caracteres sucesivos hasta que se pueda encontrar un componente léxico bien 
formado, También sería posible aplicar otras acciones con la idea de conseguir 
recuperarse del error, como por ejemplo borrar un carácter extraño, insertar un 
carácter que falte, reemplazar un carácter incorrecto por otro correcto o intercambiar 
dos caracteres adyacentes. La estrat 





ia sería aplicar alguna o varias de estas 
acciones hasta conseguir que el prefijo de la entrada restante se pueda transformar 
con un lexema válido. 





2.3.2 Especificación de componentes léxicos 


La notación más importante para especificar patrones son las expresiones 
regulares, Una expresión regular, a menudo llamada también regex, es una se: 
de caracteres que forma un patrón de búsqueda, principalmente utilizada para la 
búsqueda de patrones de cadenas de caracteres u operaciones de sustituciones. Una 
expresión regular es una forma de representar a los lenguajes regulares (finitos o 
infinitos) y se construye utilizando caracteres del alfabeto sobre el cual se define el 
lenguaje. 





Un lenguaje se refiere a cualquier conjunto de cadenas de un alfabeto fijo, 
entendiéndose por alfabeto cualquier conjunto finito de símbolos. Un ejemplo de 
alfabetos de computador son los códigos ASCII. Y por cadena sobre algún alfabeto 
se entiende una secuencia finita de símbolos tomados de esc alfabeto. 


Aunque queda fuera del alcance de esta documentación entrar en aspectos 
más teóricos sobre cadenas, lenguajes y expresiones regulares, es importante conocer 
las definiciones de operaciones sobre los lenguajes, así como las propiedades 
algebraicas de las expresiones regulares. 
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Algunos lenguajes no se pueden describir con ninguna expresión regular. 
No se pueden utilizar las expresiones regulares para describir construcciones 
equilibradas o anidadas, Si nos centramos en el conjunto de todas las cadenas 
de paréntesis equilibrados, no se puede describir con una expresión regular. Este 
conjunto se puede especificar mediante una gramática independiente del contexto, 
que se verá más adelante. 


Si damos nombre a las expresiones regulares a modo de símbolos, podemos 
entender como definición regular como una secuencia de definiciones de la siguiente 
forma: 


di->rl 
2>2 


б> т 


Donde cada dí es un nombre distinto, y cada ri es una expresión regular. 


A continuación, se muestra un ejemplo de definición regular para un conjunto 
de números sin signo, tales como /234, 56.78, 9.10E11, 9.10E-3, y para los cuáles 
se proporciona una especificación precisa mediante la siguiente definición regular: 





dígito Э [0-9] 
dígitos > dígito= 
fracción_optativa> (dígitos)? 
exponente_optativo.— > (E(+|-)?dígitos)? 


núm > dígitos fracción_optativa exponente_optativa 


2.3.3 Reconocimiento de componentes léxicos 


Si partimos de la definición regular anterior y agregamos la siguiente 
definición: 
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Podemos crear la siguiente tabla de traducción: 





< oprel MENOR 
= ор MENORIGUAL 
- oprel IGUAL 

е oprel DISTINTO 

> oprel MAYOR 

>= oprel MAYORIGUAL 


Mustración 9. Patrones de expresiones regulares para componentes léxicos. 


Los valores de los atributos de los componentes léxicos opre! (operadores 
relacionales) vienen dados por las constantes simbólicas MENOR, MENORIGUAL, 
IGUAL, DISTINTO, MAYOR y MAYORIGUAL. Esta tabla ayudará a saber qué 
hacer cuando se detecte un componente léxico en cuestión. 


Para poder reconocer los componentes léxico se hace uso de un diagrama de 
fujo estilizado denominado diagrama de transición. Estos diagramas de transición 
representan las acciones que tienen lugar cuando el analizador léxico es llamado por 
el analizador sintáctico para obtener el siguiente componente léxico. Supóngase que 
el buffer de entrada es una cadena de caracteres, y que el apuntador del principio 
del lexema apunta al carácter que sigue al último lexema encontrado. Se utiliza 
un diagrama de transición para localizar la información sobre los caracteres que 
se detectan a medida que el apuntador delantero examina la entrada. Esto se hace 
cambiando de posición en el diagrama según se leen los caracteres, 





Las posiciones en un diagrama de transición se representan con un círculo y 
se llaman estados. Los estados se conectan mediante flechas, llamadas aristas. Las 
aristas que salen del estado s tienen etiquetas que indican los caracteres de entrada 
que pueden aparecer después de haber llegado el diagrama de transición al estado s. 
La etiqueta otro se refiere a todo carácter que no haya sido indicado por ninguna de 
las otras aristas que salen de s. 








upone que los diagramas de transición de esta sección son deterministas, 
es decir que ningún símbolo puede concordar con las etiquetas de dos aristas que 
salgan de un estado. Un estado se ctiqueta como el estado /nicio, es el estado inicial 
del diagrama de transición donde reside el control cuando se empieza a reconocer un 


componente léxico. Ciertos estados pueden tener acciones que se ejecutan cuando 
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el flujo de control alcanza dicho estado. Al entrar en un estado se lec el siguiente 
carácter de entrada. Si hay una arista del estado en curso de ejecución cuya etiqueta 
concuerde con ese carácter de entrada, entonces se va al estado apuntado por la 
arista. De otro modo se indica un fallo. 


A continuación se muestra un diagrama de transición para el patrón >= y >. 
El diagrama de transición funciona de la siguiente forma:sSu estado de inicio es el 
estado 0. En el estado 0 se lee el siguiente carácter de entrada. La arista etiquetada 
соп el > del estado 0 se debe seguir hasta el estado 1 si este carácter de entrada es >. 
De otro modo, significa que no se habrá reconocido ni > ni >=. Al llegar al estado 1 
se lee el siguiente carácter de entrada. La arista etiquetada con = que sale del estado 
1 deberá seguirse hasta el estado 2 si este carácter de entrada es un =. De otro modo, 
la arista etiquetada con otro indica que se deberá ir al estado 3. El circulo doble 
del estado 2 indica que éste es un estado de aceptación, un estado en el cual se ha 
encontrado el componente léxico >=. 





Obsérvese que el carácter> y otro carácter adicional se leen a medida que se 
sigue la secuencia de aristas desde el estado inicial al estado de aceptación 3. Como 
el carácter adicional no es parte del operador relacional >, se debe retroceder un 
carácter el apuntador delantero. Se usa un * para indicar los estados en que se debe 
llevar a cabo este retroceso en la entrada. 


Si surge algún fallo mientras se está siguiendo un diagrama de transiciones, 
se debe retroceder el apuntador delantero hasta donde estaba cn el estado inicial de 
dicho diagrama, y activar el siguiente diagrama de transiciones: 





A continuación se muestra el diagrama de transiciones para el componente 
léxico oprel cuya definición regular fue definida anteriormente 
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devuelveļoprel, MENORIGUAL) 


devuelveļoprel, DISTINTO) 


devuelve(oprel, MAYOR) 


lustarción 10. Diagrama de estados para el componente léxico OPREL 


Como se puede observar, el diagrama una vez ha llegado a un estado de 
aceptación, invoca a la función devuelve cuya finalidad es asignar el atributo al 
componente léxico detectado. 


Una secuencia de diagramas de transición se puede convertir en un programa 
que busque los componentes léxicos específicos por los diagramas. Se adopta un 
enfoque sistemático que sirve para todos los diagramas de transición y que construye 
programas cuyo tamaño es proporcional al número de estados y de aristas de los 
diagramas. 





Una vez se tiene un diagrama de transición que acepte el lenguaje en cuestión, 
llega el momento de implementar el código necesario para llevar a cabo las acciones 
necesarias para cada componente léxico. Para ello se va a mostrar un ejemplo de 
implementación en C del diagrama de estados de la Ilustración 10. 











COMPILADORES 








lustración 11. Implement sición del componente léxico OPREL 





Esta función sígte_comp 
por el analizador léxico para ir obi 
que se detecte el final del código fuente. La función sigtcar() analiza el buffer en 


lex() del tipo complex será invocada secuencialmente 





ido los distintos componentes léxicos hasta 





buscar del carácter siguiente sin analizar de la cadena de entrada y lo devuelve. 





Como se puede observar en el estado inicial (0) se permiten espacios en 





blanco, tabuladores o saltos lineas. Estos caracteres son definidos como constantes, 
por ejemplo, en el fichero de cabecera (h). La manera en que los permite es 
manteniendo el mismo estado y avanzando el apuntador inicio del lexema, 
descartando dichos caracteres. De esta forma, una vez el diagrama de transición 


concuerde con algún componente léxico (en este caso solo se ha implementado uno, 
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pero podria contener muchos componentes léxicos de forma conjunta) inicio_lexema 
apuntará correctamente al inicio de la cadena que provocó que el patrón concordara 
con el componente léxico. 


En el caso de que el primer carácter sea diferente a algunos de estos caracteres 
(<,=,>) se invoca la función fallo() que restaura el estado a 0, o el que corresponda 
si hay varios estados iniciales (en el caso de implementar varios patrones), apunta 
el inicio del lexema a este nuevo carácter e invoca a la función recuperar() que 
implementará las estrategias que considere necesarias para recuperarse del error e 
intentar no abortar el análisis. 





A modo de ejemplo práctico, a continuación sc muestra el código fuente 
de un sofware real, donde se pretende analizar de manera léxica la primera linea 
de una petición HTTP, de tal forma que pueda separar las palabras existente en esa 
petición. Para ello tiene en cuenta los espacios en blanco, tabuladores y saltos de 
línea. El software escogido es thttpd v2.26, y se muestra el código de la función 
httpd_got_request() localizable en libthttpd.c:1790: 

int 


Мехр got_roquectí httad_conms hc ) 
С 





char 
Far (; hesenechas adx <heorasd idx; rebe->checked idx ) 
‹ 


с-эгеаб_Ьит1һс-эсһеске@ х1; 
эйи ( he->cheched state | 








еме сг 


саве 00127: сава “1915 
he checked stats = CHST_S0GUS; 
return ER ЕЗ REQUEST, 

агаи 








ST SENDO: 
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satê (<) 
4 
ме сс: сме сүт 
Волесь state 
break; 
саве 00127: сае түз" 
Jt The first Une Bas oly tue words - an #TTP/0.9 request. */ 
return GOUT ЖЕШЕТ, 





жет SECONDS 





tase © e ê" 
break; 

сазе \O12': case 1015 
he->cheched stats = CAST BOGUS; 
return 68 вар REQUEST: 

default. 

he-əchecked_state = снет тыттан: 








сае E 





he Scheched state 
break; 
саве 40157: 
he >cheched_state 
break: 
Ў 
break; 
сава HST THIRDS: 
Siten (€ I 


+ 
as0 `: cae E: 
bresk; 
сава 10012. 
he >cheched_state = DIST 
break; 
case 005. 
he->checked_state = ST€ 
break; 
default: 
he-xchecked state = CHST_BOGIS: 
return GR EAD REQUEST; 

‚| 

bresk; 

ease HST LDE: 

эйе бс 
4 
зе соп 
he>cheches_state = БТА; 
Break 
саа 405" 
с->еһескев «ате = CNST C; 
break; 
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3 
break: 
саа HST LF 
natch бе! 
1 
tase “onz 
ү o nevan 


return бя 007 REQUEST; 








request. */ 














case "1015" 
hesscheched state = HST CR; 
break; 
default: 
he->eheckei state = CHST LINE; 
braak: 
ر‎ 
break: 
case ST 
it 
case on 
һс-эһескей тате = сиз ги; 
break; 
case "1015", 
FA TETU an 2 row - end at ч 
fature G GOT REQUEST 
default: 
he-seheckad state = CNST LIME; 
break; 
з 
braak; 
оша HST CRLF: 
эйе (с!) 
4 
case on 


f e nalin in a 


ratura GOT REQUEST, 





case "1015" 
herschecked state = HST КА, 
break: 

кей 

he-əchecked_state = Снт ТАЕ; 









/* Tu GIFS sr ыз and ûf request. 4 
return C_COT_REOIEST: 
default: 
he Scheched state = OST LME; 
Break, 

Y 
break; 
case ERST воан. 
ratuen GRCEAD REQUEST 
т 





+ 
fetum сй ло REQUEST: 
У 
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Como se puede observar, esta implementación es algo más compleja que la 
del ejemplo anterior, aunque tan solo se encargue de detectar palabras mediante los 
caracteres que considera de separación. 


2.3.4 LEX como analizador léxico 


Según el caso, cada compilador decidirá si implementar sus propias funciones 
para el analizador léxico o reutilizar analizadores léxicos de propósito general, 
pudiendo así utilizar toda la potencia del mismo sin emplear tiempo y esfuerzo en su 
¡plementación. 





Una herramienta muy utilizada en la especificación de analizadores léxicos 
рага varios lenguajes, es la denominada LEX (en su versión de código abierto FLEX. 
(Fast Lexical Analyser) ). 





Esta herramienta es en sí un compilador que convierte código fuente en 
lenguaje LEX a código objeto en lenguaje C, tal como se muestra en la siguiente 
agen: 





Programa fuente 

















Compilador de 
en LEX A a E 
lex.1 LEX 

lex.yy.c Compilador de A 

=» Є > 

Archivo de а Secuencia de 
entrada == j —> componentes 

léxicos 











A modo de ejemplo vamos a implementar un programa LEX para los 
componentes léxicos de la Ilustración 9. 
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Como se puede observar, se limita a definir los patrones, basado en 





expresiones regulares, reglas y código en C 


De esta forma se simplifica tremendamente el códi 





respecto a la 
implementación anterior, además de ser más legible, lo que mejora los procesos de 
mantenimiento de código y depuración, 


2.4 ANÁLISIS SINTÁCTICO 


Ahora que ya somos capaces de extraer componentes léxicos del código 
nde 


'amación cuya estructura sintáctica sea de programas 


fuente, podemos pasar a la fase de análisis sintáctico. En esta fase se pre 
analizar lenguajes de pr 
bien formados, Por ejemplo, un programa que se compone de bloques, un bloque 








de proposiciones, una proposición de expresiones, una expresión de componentes 
léxicos, y así sucesivamente. Se puede describir la sintaxis de las construcciones de 
los lenguajes de programación por medio de gramáticas independientes del contexto 
o notación BNF. 





Las gramáticas proporcionan ventajas significativas a los diseñadores de 
lenguajes y a los escritores de compiladores, 
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F Una gramática da una especificación sintáctica precisa y fácil de entender 
de un lenguaje de programación. 


F A partir de algunas clases de gramáticas se puede construir 
automáticamente un analizador sintáctico eficiente que determine si un 
programa fuente está sintácticamente bien formado. También se pueden 
detectar ambigiledades sintácticas y otras construcciones difíciles de 
analizar, que de otra forma quedarían sin detectar en la fase de diseño de 
un lenguaje y su compilador. 


F Una gramática diseñada adecuadamente imparte una estructura a un 
lenguaje de programación útil para la traducción de programas fuente a 
código objeto correcto y para la detección de errores. 


F Los lenguajes evolucionan con el tiempo, adquiriendo nuevas 
construcciones у realizando tareas adicionales. Estas nuevas 
construcciones se pueden añadir con más facilidad a un lenguaje cuando 
existe una aplicación basada en una descripción gramatical del lenguaje. 


El analizador sintáctico obtiene una cadena de componentes léxicos del 
analizador léxico, y comprueba si la cadena pueda ser generada por la gramática del 
lenguaje fuente, Se supone que el analizador sintáctico informará de cualquier error 
de sintaxis de manera clara. También debería recuperarse de los errores que ocurren 
frecuentemente para poder continuar procesando el resto de su entrada. 


Los métodos empleados generalmente en los compiladores se clasifican 
como descendentes o ascendentes. Como sus nombres indican, los analizadores 
sintácticos descendentes construyen árboles de análisis sintáctico desde arriba (la 
raíz) hasta abajo (las hojas). mientras que los analizadores sintácticos ascendentes 
comienzan en las hojas y suben hacia la raíz. En ambos casos, se examina la entrada 
al analizador sintáctico de izquierda a derecha, un simbolo a la vez. 


Los métodos descendentes y ascendentes más eficientes trabajan solo 
con subclases de gramáticas, pero varias de estas subclases, como las gramáticas 
LL y LR, son lo suficientemente expresivas para describir la mayoría de las 
construcciones sintácticas de los lenguajes de programación. Los analizadores 
sintácticos implantados a mano a menudo trabajan con gramáticas LL1, mientras que 
los analizadores sintácticos para la clase más grande de gramáticas LR se construyen 
normalmente con herramientas automatizadas. 






La salida del analizador sintáctico es una representación del árbol de análisis 
sintáctico para la cadena de componentes léxicos producida por el analizador léxico. 
Además hay varias tareas que se pueden realizar durante el análisis sintáctico, como 
recoger información sobre distintos componentes léxicos en la tabla de símbolos, 
realizar la verificación de tipo y otras clases de análisis semántico. 


.com 


Libro encontrado en: www.eybooks, 
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En esta fase, el manejador de errores será capaz de detectar errores sintácticos, 
como por ejemplo, una expresión aritmética con paréntesis no equilibrados. 


2.4.1 Gramáticas independientes del contexto 


Las estructuras recursivas de los lenguajes de programación se pueden 
definir mediante gramáticas independientes del contexto. No se puede especificar 
una forma de proposición condicional usando la notación de expresiones regulares, 
En el siguiente ejemplo se muestra una proposición condicional de un lenguaje de 
programación usando la siguiente producción gramatical: 


prop > if expr then prop else prop 





Una gramática independiente de contexto o libre de contexto, consta de 


Y Terminales. 
Son los símbolos básicos con que se forman las cadenas. Cuando se trata 


de gramáticas para un lenguaje de programación, un sinónimo serían los 
componentes léxicos. Por ejemplo, las palabras clave if, then, else de la 


producción gramatical anterior. 


F No terminales. 


Son variables sintácticas que denotan conjuntos de cadenas. En la 
producción gramatical anterior, los no terminales son prop y expr: Estos 
definen conjuntos de cadenas que ayudan a definir el lenguaje generado 
por la gramática e imponen una estructura jerárquica sobre el lenguaje 
que es útil tanto para el análisis sintáctico como para la traducción. 


7 Un simbolo inicial. 
En una gramática un no terminal será considerado como el simbolo 
inicial, y el conjunto de cadenas que representa es el lenguaje definido 


por la gramática. 
F Producciones. 

Las producciones de una gramática especifican cómo se pueden combinar 

los terminales y los no terminales para formar cadenas. Cada producción 

consta de un no terminal, seguido por una flecha, seguida por una cadena 

de no terminales y terminales. Una producción formal, tiene la siguiente 

forma: 


уз» 


.com 


Libro encontrado en: www.eybooks, 
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Donde V es un simbolo no terminal y w es una cadena de terminales y/o 
no terminales. El término libre de contexto se refiere al hecho de que el 
no terminal V puede siempre ser sustituido por w sin tener en cuenta el 
contexto en el que ocurra. Un lenguaje formal es libre de contexto si hay 


una gramática libre de contexto que lo genera. 


Las gramáticas libres de contexto permiten describir la mayoria de los 
lenguajes de programación, de hecho, la sintaxis de la mayoría de lenguajes de 


programación está definida mediante gramáticas libres de contexto. Por otro lado, 
estas gramáticas son suficientemente simples como para permitir el diseño de 


eficientes algoritmos de análisis sintáctico que, para una cadena de caracteres dada 
determinen cómo puede ser generada desde la gramática. Los analizadores LL y LR. 
tratan restringidos subconjuntos de gramáticas libres de contexto. 





La notación más frecuentemente utilizada para expresar gramáticas libres de 
contexto es la forma Backus-Naur (Backus-Naur form; BNF). 

Para una explicación que permita mayor comprensión se muestra una 
gramática con las producciones que define expresiones aritméticas simples: 





expr > expr op expr 
epr > (expr) 
expr > - expr 
expr id 
op 3+ 
op>- 
>” 
op 3| 
эт 
Los símbolos terminales son: () id += */ 
Y los no terminales son: expr y op 
El símbolo inicial es: expr 
Aplicando las diferentes convenciones de notación, la gramática anterior se 
puede representar de forma abreviada y concisa como: 


E>SEAE|(E)|-Elid 
a+ 1191/11 


52. REVERSING. INGENIERÍA INVERSA ORAMA 





Los símbolos mayúsculas Æ y A son no terminales, con Æ como símbolo 
inicial. El símbolo | representa un OR lógico, y en la práctica se usa para unir 
producciones derivadas por el mismo no terminal. Es decir, E se podría haber escrito 
como: 


E>EAE 
ЕЭ(Е) 
E>-E 
E> id 


El resto de los símbolos son terminales. Esta gramática generaría por ejemplo 
la cadena: 


(к +у)*х-2*у/(х+х) 


2.4.2 Arboles de análisis sintáctico y derivaciones 


Existen básicamente dos formas de describir cómo en una cierta gramática 
una cadena puede ser derivada desde el simbolo inicial. La forma más simple es 
listar las cadenas de símbolos consecutivas, comenzando por cl símbolo inicial 
y finalizando con la cadena y las reglas que han sido aplicadas. Si introducimos 
estrategias como reemplazar Siempre el no terminal de más a la izquierda primero, 
entonces la lista de reglas aplicadas es suficiente. A esto se le llama derivación por la 
izquierda. Por ejemplo, si tomamos la siguiente gramática: 





LS=S+S 
2s>1 


Y la cadena “1 + 1 + 1”, su derivación a la izquierda está en la lista [(1) (1) 
(2) (2) (2)]. Análogamento, la derivación por la derecha se define como la lista que 
obtenemos sí siempre reemplazamos primero el no terminal de más a la derecha. En 
ese caso, la lista de reglas aplicadas para la derivación de la cadena con la gramática 
anterior sería la [(1) (2) (1) (2) 2) 


La distinción entre derivación por la izquierda y por la derecha es importante, 
porque en la mayoría de analizadores la transformación de la entrada es definida 
dando una parte de código para cada producción, que es ejecutada cuando la regla 
es aplicada. De modo que es importante saber qué derivación aplica el analizador, 
porque determina el orden en el que el código será ejecutado. 
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Una derivación también puede ser expresada mediante una estructura 
jerárquica sobre la cadena que está siendo derivada. Por ejemplo, la estructura de 
la derivación a la izquierda de la cadena “1 + 1 + 1" con la gramática anterior sería: 


S8+S (1) 

$—5+5+5 (1) 

5155-5 0) 

S=1+1+S (2) 
S=1+1+1 (2) 

{44115 + {1]5]5 + {1]815 


Donde {...}$ indica la subcadena reconocida como perteneciente a S. Esta 
jerarquia también se puede representar mediante un árbol sintáctico: 


ON, 
NN, 
pl 


1 1 


Este árbol es llamado árbol de sintaxis concreta de la cadena, En este caso, 
las derivaciones por la izquierda y por la derecha, presentadas, definen la sintaxis 
del árbol. Sin embargo, hay otra derivación (por la izquierda) de la misma cadena. 

La derivación por la derecha: 

S>S+S(1) 

S>1+S(2) 

S>1+S+S(1) 

S1+1+S() 

So 1+1+1() 
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Define el siguiente árbol sintáctico: 


м. 
| М 


“Н 


Si para una cadena del lenguaje de una gramática hay más de un árbol 
posible, entonces se dice que la gramática es ambigua. Normalmente estas gramáticas 
son más difíciles de analizar porque el analizador no puede decidir siempre qué 
producción aplicar. 


Los árboles de análisis sintáctico son utilizados por el analizador sintáctico 
para llevar a cabo el análisis sintáctico. Depende la estrategia utilizada se denominan 
de una forma u otra: 


F Análisis sintáctico descendente. 


Se considera a encontrar una derivación por la izquierda para una cadena 
de entrada, tratando de construir un árbol de análisis sintáctico para la 
entrada comenzando por la raiz y creando los nodos del árbol en orden 
previo. 


El analizador sintáctico LL es un analizador sintáctico descendente, 
por un conjunto de gramática libre de contexto. En este analizador las 
entradas son de izquierda a derecha, y construcciones de derivaciones por 
la izquierda de una sentencia o enunciado. La clase de gramática que es 
nalizable por este método es conocida como gramática LL. 


P Análisis sintáctico ascendente 


En su estilo general es conocido como análisis sintáctico por 
desplazamiento y reducción. Este tipo de análisis intenta construir un 
árbol de análisis sintáctico para una cadena de entrada que comienza por 
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las hojas y avanza hacia arriba, la raíz. Se puede considerar este proceso 
como de reducir una cadena al símbolo inicial de la gramática. 


Los analizadores sintácticos LR, también conocidos como Parser LR, 
son un tipo de analizadores para algunas gramáticas libres de contexto. 
Pertenece a la familia de los analizadores ascendentes, ya que construyen 
el árbol sintáctico de las hojas hacia la raíz. Utilizan la técnica de análisis 
por desplazamiento reducción. Existen tres tipos de parsers LR: SLR (K), 
LALR (K) y LR (K) canónico. 





2.4.3 Analizadores sintácticos LR 


Es una técnica de análisis sintáctico ascendente que se puede utilizar para 
analizar una clase más amplia de gramáticas independientes del contexto. La técnica 
se denomina LR(4), donde L es por el examen de entrada de izquierda а derecha (lefi- 
to-right), la R por construir una derivación por la derecha (rigthmost derivation) en 
orden inverso, y k por el número de símbolos de entrada de examen por anticipado 
utilizados para tomar las decisiones del análisis sintáctico. Cuando se omite, se 
asume que kes 1. 


F Un analizador LR consta de: 

I Un programa conductor 

P Una entrada 

F Una salida 

F Una tabla de análisis sintáctico, compuesta de dos partes (ACCIÓN Y 
GOTO). 


Cabe acotar que el programa conductor es siempre igual, solo variando para 
cada lenguaje la tabla de análisis sintáctico. La tabla de análisis sintáctico se extrae 
del diagrama de transición de estados teniendo en cuenta los k simbolos de entrada 
de examen por anticipado y cl estado actual. De esta forma si se está en un estado se 
sabe a qué estado ir y qué acción tomar, observando los k simbolos de examen por 
anticipado. 


El algoritmo para reconocer cadenas es el siguiente: dado el primer carácter 
de la cadena y el estado inicial de la tabla, buscar qué acción corresponde en la tabla 
de acción. 


Si el estado es shift n (n € N), se coloca el carácter y el número de estado 
en la pila, se lee el siguiente carácter y repite el procedimiento, solo que esta vez 
buscando en el estado correspondiente. 
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SI ACCIÓN = REDUCE n (n €N), se sacan de la pila tantas tuplas (estado, 
simbolo) como el largo de la cola de la producción en el n-ésimo lugar, y se reemplaza 
por la cabeza de esta producción. El nuevo estado sale de buscar en la tabla GOTO 
usando para ubicarlo el número de estado que quedó en el tope de la pila, y el no 
terminal en la cabeza. 





En la tabla acción también se encontrará ACEPTAR (que se toma la cadena 
¡como válida) y se termina el análisis o ERROR (que se rechaza la cadena). 


2.4.4 Analizadores sintácticos LALR 


El analizador sintáctico LALR (Jookahead-LR) o análisis sintáctico LR con 
simbolo de anticipación, se utiliza a menudo en la práctica porque las tablas con él 
obtenidas son bastante más pequeñas que las tablas del análisis LR canónico, y las 
construcciones sintácticas más frecuentes de los lenguajes de programación pueden 
expresarse convenientemente con una gramática LALR. 
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La traducción de lenguaje guiada por gramáticas independientes del 
contexto, se conoce por traducción dirigida por la sintaxis. Esto es lo que se entiende 
рог análisis semántico. 

Se asocia información a una construcción del lenguaje de programación 
proporcionando atributos a los simbolos de la gramática que representan la construcción. 
Los valores de los atributos se calculan mediante reglas semánticas asociadas a las 
producciones gramaticales. Hay dos notaciones para asociar reglas semánticas con 
producciones, las definiciones dirigidas por la sintaxis y los esquemas de traducción. 
Las definiciones dirigidas por la sintaxis son especificaciones de alto nivel para 
traducciones. Ocultan muchos detalles de la implementación y no es necesario que el 
usuario especifique explicitamente el orden en el que tiene lugar la traducción. 


Las definiciones dirigidas por la sintaxis, como con los esquemas de 
traducción, se analizan sintácticamente la cadena de componentes léxicos de entrada, 
se construye el árbol de análisis sintáctico y después se recorre cl árbol para evaluar 
las reglas semánticas en sus nodos. La evaluación de las reglas semánticas puede 
generar código, guardar información en una tabla de símbolos, emitir mensajes de 
error o realizar otras actividades. 


A modo de ejercicio didáctico, se va a proceder a construir una calculadora 
muy sencilla que lea una expresión aritmética, la evalúe y después imprima su 
valor numérico, Para ello comenzaremos definiendo la siguiente gramática para 
expresiones aritméticas. 
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E>E-T|T 
T>3T*F|F 
F > (E) | digito 


Nustración 12.6 





Con esto ya podemos definir un programa fuente en YACC (Yet Another 





Compiler-Compiler). en concreto vamos a utilizar Bison. Yacc es un programa para 


generar analizadores sintácticos. Genera un analizador sintáctico basado en una 





gramática analítica escrita en una notación similar a la BNF. Se usa normalmente 
acompañado de FLEX aunque los analizadores léxicos se pueden también obtener 
dor léxico debido a 
YACC y Bison 
mación C 


de otras formas. De hecho, en el ejemplo siguiente, el anali: 














e en YACC seria el siguiente 
propuesto: 
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Este código define un token DIGITO, que es el terminal digito de la gramática. 
з de la traducción. Estas reglas contienen la 






A continuación se definen las re 


producción de la gramática y una regla semántica asociada, El símbolo $$ se refiere 





al no terminal de la izquierda de la producción, y cada $n se refiere a cada terminal 


a na terminal del lado derecho de la producción. 


YACC utiliza la función yy/ex() como analizador léxico, que se encarga de 
léxico y su valor de atributo asociado. 





producir pares formados por un compone 
En este caso solo hay un componente léxico declarado en la primera sección de 
la especificación de YACC, como DIGITO. El valor del atributo asociado a un 
componente léxico se comunica al analizador sintáctico mediante la variable yylval. 


Este analizador léxico es solo a modo de ejemplo, pero lo más común es 
utilizar LEX, de tal forma que en lugar de reescribir la función yylex(), nos limitamos 
nerado por FLEX partiendo del pr 

léxico, por ejemplo /ex.yy.c. Tal y como se ve en el código siguiente modificado del 


aincluirel código en C 'ama fuente del analizar 





anterior: 





Moustración 13. calcul: 





Donde el código del analizador léxico escrito en LEX sería el siguiente: 


Е 
8 
8 
2 
8 
a 
© 
5 
2 
5 
© 
E 
£ 
E 
5 
8 
в 
5 
2 
5 
3 
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Mustración 14. lexl 


Con estos dos ficheros, podemos utilizar FLEX y BISON para compilar la 
calculadora aritmética, construida partiendo de la gramática de la Ilustración 12 con 


los siguientes comandos: 


5 Mex lex.1 
5 bison caleuladora.y 
$ gcc calculadora.tac.c -o calculadora 


Una vez se ejecute el binario calculadora se podrán escribir expresiones 


aritméticas, como las definidas en la gramática, y tras pulsar Enter, se mostrará el 


resultado, 


2.6 GENERACIÓN DE CÓDIGO INTERMEDIO 


Después de los análisis sintáctico y semántico, algunos compiladores g 
una representación intermedia explicita del programa fuente. Se puede considerar 
esta representación intermedia como un programa para una máquina abstracta, Esta 
debe tener dos propiedades importantes: debe ser fácil de producir y fácil de traducir 





al programa objeto 
Las ventajas de utilizar una forma intermedia independiente de la máquina son: 


FF Poder crear un compilador para una máquina distinta uniendo una etapa 
final рага la nueva máquina a una etapa inicial ya existente. 
F Poder aplicar a la representación intermedia un optimador de código 


independiente de la máquina 
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2.6.1 Código de tres direcciones 


Paracumplircon las dos propiedades importantes mencionadas anteriormento, 
se desarrolla una clase de representación intermedia, cuyas reglas semánticas para 
generar código a partir de construcciones de lenguajes de programación comunes 
son similares a las reglas para construir árboles sintácticos. Esta representación 
intermedia se conoce como código de tres direcciones. Este término viene dado 
porque cada proposición contiene generalmente tres direcciones, dos para los 
operandos y una para el resultado. 





El código de tres direcciones es una secuencia de proposiciones de la forma 
general: 


yopz 





Donde x.y y z son nombres, constantes o variables temporales generadas 
por el compilador; ор representa cualquier operador, como un operador aritmético 
de punto fijo o flotante, o un operador lógico sobre datos con valores hooleanos. 
Téngase en cuenta que no se permiten expresiones aritméticas compuestas, pues solo 
hay un operador en el lado derecho de una proposición. Por tanto, una expresión del 
lenguaje fuente como x+y*z se puede traducir en una secuencia: 


а 
2 


2 
хеп 





Donde t1 y t2 son nombres temporales generados por el compilador. Esta 
descomposición de expresiones aritméticas complejas y de proposiciones de flujo 
del control anidadas, hace al código de tres direcciones descable para la generación 
de código objeto y para la optimación. 


2.6.2 Tipos de proposiciones de tres direcciones 


Las proposiciones de tres direcciones son análogas al código ensamblador. 
Las proposiciones de tres direcciones más comunes son las siguientes: 


F Proposiciones de asignación. 


Se denominan así a las que tienen la forma x = y op Z, donde op es 
una operación binaria aritmética o lógica. Una definición dirigida por la 
sintaxis para producir código de tres direcciones para las asignaciones es 
el siguiente: 
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БЕТЕН Sodio >= Ecodigo| en lugar‘: E lugar) 
E ugar += temnuevo: 
ESENE E codigo =" ELeodigo | E2.codigo | 
'BEm(E lugar "x` El lugar “+° E2 lugar) 
E lugar = temnmevo: 
E ŞEI*E2 Ecodigo >= Е1 сойо | E2.codigo | 
gen lugar *:=" El lugar **" EZ lugar) 
SA E ugar += temnuevo: 
Ecodigo =" El-codigo | gen(E lugar: "menusa” El Juga) 
E>) Elgar: Elmar 
кэм Еннио 





Donde £ lugar es el nombre que contendrá el valor de E, y E.codigo es la 
secuencia de proposiciones de tres direcciones que evalúan £. La función 
tempnuevo devuelve una secuencia de nombres distintos tl, (2, ..., tn, 
en respuesta a sucesivas llamadas. Y la función gen que se utiliza para 
representar la proposición de tres direcciones 


Instrucciones de asignación. 


Las instrucciones de asignación de la forma x — op y, donde op es una 
operación unaria. Las operaciones unarias principales incluyen el menos 
unario, la negación lógica, los operadores de desplazamiento y operadores 
de conversión que, por ejemplo, convierten un número de punto fijo en 
un número de punto flotante. 


Proposiciones de copia. 


De la forma x += y, donde el valor de y se asigna a x. 





Saltos condicionales. 





Tales como if x oprel y goto E. Esta instru 
relacional (<, ete.. )ax 
con etiqueta E si x pone oprel en relación con y. Si no, a continuación se 
ejecuta la proposición de tres direcciones que sigue a if x oprel y goto 
E, como en la secuencia habitual. Una definición dirigida por la sintaxis 


ción aplica un operador 





y a continuación ejecuta la proposición 





para producir código de tres direcciones para las proposiciones while 
ia la siguiente: 
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S> IFE then SI else S2 





F Llamadas a procedimientos. 
De la forma: 
param x1 
param x2 
param xn 
call p, n 


Donde p es el procedimiento, xn son los parámetros y n es el valor 
devuelto, que es opcional. 


F Asignaciones con índices. 


De la forma x:= yfi] y x[i] = y. La primera asigna a x el valor de la 
posición en i unidades de memoria más allá de la posición y. La otra 
proposición asigna al contenido de la posición en i unidades de memoria 
más allá de la posición x al valor de y. En ambas instrucciones, x, y ei se 
refieren a objetos de datos. 
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F Asignaciones de direcciones y apuntadores. 





De la forma x= у, х = *y y *x := y. La primera hace que el valor de 
x sea la dirección de y. y será un nombre, tal vez una variable temporal, 
que indica que el valor de lado derecho de x es el valor de lado izquierdo 
(posición) de un objeto. En la proposición x := *y, se supone que y es 
un apuntador a una variable temporal cuyo valor de lado derecho es una 
posición. El valor de lado derecho de x se iguala al contenido de dicha 
posición. Por último, *x := y hace que el valor de lado derecho del objeto 
apuntado por x sea igual al valor de lado derecho de y. 








2.7 GENERACIÓN DE CÓDIGO Y OPTIMIZACIONES 





Llegados a esta última fase de compilación, se procede a traducir el código 
intermedio a código objeto. Gracias a las propiedades del código intermedio, la 
traducción es directa. Dependiendo de la arquitectura para el que está destinado y el 
sistema operativo, las instrucciones a generar variarán en gran medida. 


Matemáticamente, el problema de generar código óptimo es indecidible. En 
la práctica, hay que conformarse con técnicas heurísticas que generan código bueno 
pero no siempre óptimo. 


Idealmente, los compiladores deberian producir código objeto que fuera 
tan bueno como para ser escrito a mano. La realidad es que este objetivo solo se 
alcanza en pocos casos, y difícilmente. Sin embargo, a menudo se puede lograr que 
el código directamente producido por los algoritmos de compilación se ejecute más 
rápidamente, o que ocupe menos espacio, o ambas cosas. Esta mejora se consigue 
mediante transformaciones de programas que tradicionalmente se denomina 
optimaciones, aunque el término optimación по es adecuado porque rara vez existe 
la garantía de que el código resultante sea el mejor posible. 


A continuación se muestran las principales fuentes para la optimación: 


F Transformaciones que preservan la función. 


El compilador utiliza muchas formas para mejorar un programa sin 
modificar la función que calcula. Por ejemplo: 





Eliminación de subexpresiones comunes. 
Propagación de copias. 

Eliminación de código inactivo. 

Calculo previo de constantes. 
Transformaciones algebraicas. 
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F Subexpresiones comunes. 


Una ocurrencia de una expresión £ se denomina subexpresión común si 
E ha sido previamente calculada y los valores de las variables dentro de 
E no han cambiado desde el cálculo anterior. Se puede evitar recalcular 
la expresión si se puede utilizar el valor calculado previamente. En el 
siguiente ejemplo de código intermedio: 


ANTES 





10 = 4*j >2 
а[по] 
goto B2 





Se observa como 17 y 110 tienen las subexpresiones común 4% y 4% 
respectivamente. Es por esto que pueden ser eliminadas de la siguiente 
forma: 


DESPUÉS 





De esta forma el código no varía sus resultados y sin embargo se ahorra 
espacio y tiempo de computación. 


F Propagación de copias. 


Se trata de sustituir variables por copias a las mismas. Concierne a las 
asignaciones de la forma f = g llamadas proposiciones de copia o copia 
simplemente. La idea en que se basa la transformación de propagación 
de copias es utilizar g por f, siempre que sea posible después de la 
proposición de copia f = g. Por ejemplo, la siguiente asignación x := 13 
es una copia: 
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F Eliminación de código inactivo 


Una variable está activa en un punto de un programa si su valor puede 
ser utilizado posteriormente, en caso contrario está inactiva en ese punto. 
Lo mismo se puede decir del código inactivo o inútil, proposiciones que 
calculan los valores que nunca llegan a utilizarse. Aunque es improbable 
que el programador introduzca código inactivo intencionadamente, puede 
aparecer como resultado de transformaciones anteriores. Por ejemplo, el 
uso de una variable que se asigna a falso o verdadera en varios puntos del 
programa para depurar el código: 


If (depura) print ... 


Mediante el análisis de flujo de datos, es posible concluir que cada vez 
que el programa alcanza dicha proposición, el valor de depura es falso. 
Generalmente, lo es porque hay una proposición determinada: 


depura = false 





que se puede considerar la ultima asignación a depura antes de hacer 
la comprobación, independientemente de la secuencia de ramificaciones 
que tome en realidad el programa. Llegados a este punto al evaluar la 
condición, se comprueba que la expresión no se cumplirá nunca y por lo 
tanto el print tampoco, esto se considera código inactivo y será eliminado 
del programa objeto. 


La propagación de copias tiene como ventaja que a menudo se convierte 
la proposición en código inactivo. Por ejemplo, en el ejemplo anterior, 
si tras la propagación de copias va la eliminación de código inactivo, la 
asignación a x se eliminaría: 

ANTES 
B 
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DESPUÉS 
аро]:=15 
ара 





F Optimaciones de lazos. 


Esta transformación es especialmente importante, sobre todo en los 
lazos internos donde los programas tienden a emplear la mayor parte 
de su tiempo. El tiempo de ejecución de un programa se puede mejorar 
si se disminuye la cantidad de instrucciones en un lazo interno, incluso 
si se incrementa la cantidad de código fuera del lazo. Hay tres técnicas 
importantes para la optimación de lazos: 


+ Traslado de código. 


Esta importante modificación disminuye la cantidad de código en un 
lazo. Para ello se toma una expresión que produce el mismo resultado 
independientemente del número de veces que se ejecute el lazo y 
coloca la expresión antes del lazo. Por ejemplo: 


ANTES 
while ( 





limite —2) 
DESPUÉS 

t= limite - 
while (i 


La proposición no cambia limite nì t. 





+ Eliminación de variables de inducción. 
Detección de variables de inducción, es decir variables que 
incrementan/decrementan su valor en un buele, para cambiar por 
ejemplo una multiplicación por una resta que emplea menos tiempo 
de proceso en su cálculo. En el siguiente ejemplo se puede ver un 
código con dicho comportamiento: 


ANTES 





15 alta] 
ift5 >v вою ВЗ 
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DESPUÉS 
4j 








15 = aft4] 
¡FIS >v goto B3 


Una vez identificadas las variables de inducción, se tratará de de 
utilizar solo sumas y restas en lugar de multiplicaciones o divisiones, 
esto se denomina reducción de intensidad. 





F Otras optimizaciones 


Además de las vistas anteriormente, que se centran en la transformación 
de instrucciones, hay otras transformaciones que afectan a la estructura 
del programa. Como pueden ser las optimizaciones de bloques básicos, 
donde se implantan mediante la construcción de un grafo dirigido aciclico 
para un bloque básico, es decir, un grafo dirigido que no tiene ciclos 
y evita que exista problema de bucles infinitos; Lazos en los grafos de 
flujo, donde se pretende reducir las aristas del grafo de control de flujo 
que generan los flujos de datos. La siguiente imagen muestra diferentes 
grafos de control de flujo: 





IE While 

Secuencia A Га ¥ 

ое dla pa y 
Case 


Por último se realiza el análisis global de flujo de datos, donde el 
compilador necesita reunir información sobre el programa como un 
todo y distribuir esta información a cada bloque en el grafo de flujo. 
La información del lujo de datos se puede recopilar estableciendo 
y resolviendo sistemas de ecuaciones que relacionan la información 
en varios puntos de un programa. Estas ecuaciones se conocen como 
ecuaciones de flujo de datos. 
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2.8 HERRAMIENTAS PARA LA COMPILACIÓN 





Resulta extremadamente útil el estudio y análisis de compiladores se uso 
general, como puede ser GCC (GNU Compiler Collection) o LLVM.A diferencia de 
GCC, LLVM está diseñado para ser muy modular, reutilizable y con capacidad para 
generar código de diversas arquitecturas desde una misma máquina con arquitectura 
diferente (cross-compiler). Aunque GCC también es capaz de hacerlo no se diseñó 
con ese fin, lo que hace a LLVM más útil en este aspecto. LLVM está más orientado 
a la interacción con el usuario, por lo que resulta más atractivo para llevar a cabo 
labores de desarrollo en partes concretas del proceso de compilación, en lugar de 
utilizar el compilador como un todo, como en el caso de GCC, que aunque es posible 
realizarlo igualmente, al no estar desarrollado para este fin, resulta más complicado. 


A modo de ejemplo se muestra cómo es posible utilizar las librerías de 
LLVM desde Python para generar un árbol sintáctico, y generar código objeto final 
sin necesidad del código fuente inicial. Esto demuestra la potencia de LLVM para 
acceder a cualquier fase de compilación y la interactividad con la que se pueden 
realizar modificaciones o compilaciones “al vuelo”. 


El siguiente ejemplo es parte del paquete llvmpy y el código fuente se puede 
encontrar en el siguiente enlace: 
Y hups://github.com/llvmpy/llmpy/blob/master/tesVexample-jit.py 
2 from 1bvn import * 


fron 11va.core inport * 


fron 1va.ee inport * 2 rt: єє = Execution Engine 





inport Logging 
Import unttest 


class TostExanpleJET(unittest.TestCaso) 
def tasto elf}: 
Create a moduls, a доле exampl 
ту-лофДе = Мофйепен('пу воёдйе') 
Ey_ánt = Type. int() t 32 
ty_fune = Type function(ty_3nt, [ty Ant, tyint]) 
и Fun = ny_sodule.add_function(ty Func, “sun") 
1 Tsun. args [E] nane = "a" 
Tsun args [1] nare = "n= 
DD = sun. appena_basic_biceK[ “ent: 
эд1йфәг = ад1гг пем) 
бар = buzidor.ado(f_sun.arge[0), f_sun.args[t], “tap") 
4 sunlder,ret(tnp) 
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1 create a 
platforms Cat step or an interpreter othe 
ExecutionEngine.rew[ay_nodule) 





a execu 





mpiler 








= The argument: ' 


a argl_value = 199 
эга узше = 12 











GenaracYalue.Ant(2y 38, argl value) 
aro? = GensricVadue int(ty_3nt, arg? value) 








4 Now let's совре апе 


retval = ee.run_fonction{f_sum, [arg1, arg2]) 





е 2 The retum valse ts алы 


1oggLng.debug( “returned sa" 


retval.2s_1 








x Salt .assertEqual(retval.asint(), (argi valus + arg2_value)) 


Analizando el código, se ve cómo en la línea 15 se genera un módulo, sobre 
el que se insertará el código en sí. En las líneas 16 y 17 se definen dos tipos de datos, 
una variable y una función. Posteriormente se crean la función denominada “sum” 
en la línea 18, y se establecen nombres para los argumentos en las lineas 19, 20. 
Luego se crea un bloque básico denominado “entry” para la función “sum” creada 
anteriormente, Finalmente se procede a definir el valor de retorno en la línea 23, que 
сото se observa, le dice que simplemente sume los dos argumentos y nombra esa 
variable como “tmp”. En la linea 24 construye el valor de retomo para la función, y 
ya quedaría la función totalmente compilada. 


Una vez tenemos montada la función, se procede a instanciar el motor de 
ejecución en el módulo creado, y declara unas variables a modo de argumentos para 
la función, en las líncas 28-35. Finalmente se procede a invocar la función con esas 
dos nuevas variables, almacenando el resultado en una variable de Python en la linea 
38. 





El código objeto generado por estas acciones llevadas a cabo, serían el 
equivalente a un código fuente como este: 
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Mustraciön 15 fases. 


El contenido de la función main, no está definido explicitamente en el 
ejemplo, ya que se centra en la función y retval no está definida como variable, solo 
se utiliza en el contexto del código de Python, pero se ha establecido así por claridad. 


Con GCC también es posible llevar a cabo un ejercicio similar. En el 
¡guiente enlace se muestra un ejemplo: 








Y https://gcc.gmu.org/onlinedoes/gcc-5.1.0/jit/intro/tutorial01-htmb 


Otras de las cosas interesantes que se pueden hacer, es consultar los detall 





de cada una de las fases por las que pasa el compilador, convirtiendo el código fuente 
en código máquina. Para ello usaremos GCC y el 
la Hustración 15 





mplo anteriormente descrito en 
¡remos diciéndole que nos muestre información sobre las fases. 





En primer lugar, vamos a ver qué fases y optimizaciones tiene activada por 


defe 





«cto, con el siguiente comando: 


EEE 





Mostrando el siguiente resultado (acortado por cuestiones de espacio): 


a 


3 
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Ahora podemos pasar a generar todos los ficheros de las fases con el siguiente 
comando bastante completo: 


ашар їра-а11 —о їавев 





кт 


nerados por el comando: 





A continuación se listan todos los ficheros 

















El número exacto difi de GCC, pero el nombre final si es 
descriptivo sobre lo que contiene el fichero. Aunque son especialmente interesantes 


las siguientes: 





RAMA 








F fas 
Flow Graph (CFG). 


¡co de control de flujo o Control 





c.014t.efg: construcción del 
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0180.5а: conversi 





la forma SSA (Static Single Assignment). 





F fases.c.149t.optimized: el resul 





ado 





después de todas las 
optimizaciones GIMPLE 








RAMA 





COMPILADORES 85 





Se deja como ejercicio al lector examinar el resto de ficheros y la 





documentación oficial de GCC para obtener una mayor comprensión de los mismos. 


2.9 CUESTIONES RESUELTAS 


2.9.1 Enunciados 


1. ¿Cuál de estas instrucciones están representadas en notación Intel?- 


а. mov $0x6008c8,%rdi 
b. mov qword ptr [rsp-0x8].r15 
с. mov Ox18(%rsp).%r12 
d. mov %r14.-0x10(%rsp) 

2. Ordena las sig 


uientes fases en el proceso de compilación: 





a. Generación de código intermedio 





b. Análisis semántico 
e. Generación de código objeto 
d. Análisis 
£ 





Optimación de código 
Análisis sintáctico 


3. ¿Con qué tipo de recurso no puede ser especificada esta forma de 
proposición?: 


oro encontrado en: www,eybooks, com 
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expr > expr op expr 
expr > (expr) 
expr > - expr 
expr > id 
op >+ 
op >- 
>” 
орЭ! 
Э 1 
a. Analizador LR 
b. Expresiones regulares 
с. Analizador LALR 
d. Analizador LL 
4. ¿Qué cadena pertenece al lenguaje definido por la siguiente expresión 
regular? 
alable)+b 
a. acabacb 
b. acab 
c. aabeabeabaab 
d. acabcb 
5. A qué expresión regular representa el siguiente diagrama de transición 
de estados: 





a. albjce*)dab 
b. albjce*dab) 
e. a(ce*dab)b 
de a(bice*da)b 
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6. ¿Qué tipo de optimización se puede llevar a cabo en el siguiente código?: 





a. Propagación de copias 
b. Eliminación de código inactivo 
e. Traslado de código 

d. Subexpresiones comunes 


7. De la siguiente gramática, indique cuáles son los no terminales: 
S>(L)la 
L3L:S|S 


а. 8, Э,| 
ъ ба: 
e аб) 
4. 51. 


8. ¿Qué fase de compilación se encarga de detectar los tokens en el código 
fuente?: 


a. Análisis semántico 
b. Análisis sintáctico 


e. Análisis morfológico 
d. Análisis léxico 


9. ¿Qué es una secuencia de caracteres en el programa fuente con la que 
concuerda el patrón para un componente léxico?- 
a. Patrón 
b. Token 
с. Lexema 
d. Componente léxico 


10.¿Qué es una serie de reglas que deciden si un conjunto de cadenas de 
entrada cumplen o no con esa especificación”: 
a. Lexema 
b. Token 
e. Patrón 
d. Gramática 
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2.9.2 Soluciones 


aRoraras 


lL. fb, a, e.e 


2.10 EJERCICIOS PROPUESTOS 


Construya con flex y bison una calculadora aritmética utilizando la 
siguiente gramática 


E ŞE+E|E-E|E*E|E/E|(E)|-E | numero 


Basándose en el siguiente código en C 


+ velocidad * 





Compile el código con GCC y a través de los ficheros de información de 
las fases de compilación, trate de determinar las optimizaciones que se 
han llevado a cabo. Luego vuelva a repetir el ejercicio pero añadiendo el 
argumento -00 al compilador GCC para desactivar las optimizaciones y 
compare los resultados. 





RECONSTRUCCIÓN DE CÓDIGO l. 
ESTRUCTURAS DE DATOS 


Introducción 


En esta unidad se hará un repaso de los tipos de datos más importantes y 
comunes en C/C++ desde un punto de vista de implementación a código objeto. Por 
cada uno de ellos se verá su implementación en varias arquitecturas, x86/32-64 bits 
y ARM. 


Objetivos 


Cuando el alumno finalice esta unidad, será capaz de identificar estructuras 
de datos en código ensamblador de varias arquitecturas. Desde variables con tipos 
básicos, así como estructuras y objetos con invocación a métodos virtuales mediante 
tablas virtuales. 


3.1 CONCEPTOS BÁSICOS SOBRE RECONSTRUCCIÓN DE CÓDIGO 





En el tema anterior hemos profundizado en el proceso de compilación, 
que convierte el código fuente, escrito en un lenguaje estructurado de alto nivel 
y fácilmente comprensible por una persona, en código objeto escrito en lenguaje 
máquina, para la arquitectura escogida y directamente ejecutable. 





Ahora conocemos los conceptos básicos sobre diseño, análisis e 
implementación de lenguajes, así como los detalles sobre las fases por las que pasa 
un compilador, las técnicas utilizadas para generar y optimizar el código objeto y 
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en definitiva, todo lo relacionado con el proceso de compilación que genera código 
objeto partiendo de código fuente. 


Ya sabemos cómo el compilador convierte el código fuente a código 
intermedio, utilizando éste finalmente, para traducirlo a código máquina de manera 
n, extraida de la Hustración 8: 








directa, tal y como podemos ver en la siguiente im: 








Esto hace intuir que pudiera existir alguna forma de revertir el proceso, 


pudiendo generar código fuente a partir del código objeto en lenguaje máquina 





Esta labor sí es posible en gran medida, aunque se deben tener en cuenta las 
limitaciones explicadas en el apartado 1.3 donde sc enumeran dichas las limitaciones 
en el campo de la ingeniería inversa. 
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En este tema, vamos a referirnos como reconstrucción de código al proceso 
inverso al que hemos estado estudiando en el tema anterior. Es decir, al proceso 
de obtener cl código fuente, a partir del código objeto. Debido a las limitaciones 
comentadas, no será posible obtener comentarios, ni nombre de variables tal y como 
las describió cl desarrollador, puede que ni tan siquiera con el tipo ni tamaño exacto 
con el que éste lo hizo. Los motivos se explican en el apartado 1.3 de limitaciones 
ya mencionados. 


No obstante, si se va a poder obtener una estructura de código que cumple 
соп bastante exactitud el comportamiento del programa fuente. Para ello es necesario 
conocer las estructuras que el compilador maneja, y con las que traduce el código 
fuente a código objeto. De esta forma podremos identificar estas estructuras en el 
código objeto y ser traducidas a código fuente. 


Esta traducción depende de: 


P Arquitectura objeto. 


Un mismo código fuente puede ser compilado para distintas arquitecturas 
como pueden ser x86 en 32 bits o 64 bits; ARM con Thumb o Thumb-2; 
MIPS con Big Endian o Little Endian, u otras. 





W Optimizaciones. 


Aunque el compilador sítiene una traducción exacta entre el código fuente 
a código intermedio y de código intermedio a código objeto, se llevan 
a cabo optimizaciones de código incluso del objeto, que dependiendo 
del contexto local o global del código intermedio y/o el código objeto, 
son susceptibles de ser modificados al aplicarse tras aplicar técnicas de 
optimización. 





Una vez traducidas estas estructuras, podremos continuar el proceso 
de ingenieria inversa analizando los datos, dándoles nombres significativos a las 
variables, estructuras y funciones, incluso agregando comentarios y/o anotaciones 
en el código reconstruido. 


En este tema y en el siguiente, se pretende mostrar los tipos de datos, 
estructuras e incluso algoritmos utilizados comúnmente en el software, de tal forma 
que sea posible identificarlos y traducirlos de manera directa a código fuente. Para 
ello se van a mostrar ejemplos en lenguaje C/C++ y el código objeto generado para 
diferentes arquitecturas. 
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Se tratará de mostrar un número significativo de escenarios, así como la 
metodología de análisis de los mismos, para dotar al lector de autonomía suficiente 
como para afrontar otros escenarios no contemplados aquí, como pueden ser otras 
arquitecturas, o incluso otros lenguajes fuente. 


En este capítulo en y el siguiente los ejemplos del código objeto serán 
principalmente código ensamblador x86/32 bits. Mostrándose paralelamente x86/64 
bits si las diferencias son significativas y ARM u otras arquitecturas siempre que sea 
posible, para mostrar claramente otras perspectivas. 





Enel caso de ARM, es posible compilar los ejemplos utilizando compiladores 
cruzados (Cross-Compilers), que permiten compilar desde una máquina con una 
arquitectura, por ejemplo x86, a código objeto en otra arquitectura, en este caso 
ARM. 


Para los códigos mostrados en este tema y el siguiente se ha utilizado cl 
compilador GCC (GNU Compiler Collection) y el depurador GDB (GNU Debugger) 
en una plataforma Linux. Queda como labor del lector realizar estos ejemplos con 
otros compiladores y comprobar por sí mismo las diferencias y similitudes con las 
aquí expuestas. 


Vamos a introducimos en la reconstrucción de código partiendo de las 
estructuras de datos disponibles en el lenguaje C- Trataremos los tipos de datos más 
básicos como variables, hasta los más complejos como pueden ser los objetos del 
paradigma de los lenguajes de orientados a objetos, utilizados en C+. 


3.2 VARIABLES 





La estructura de datos más simple utilizada en C, son las variables. Estas se 
pueden implementar de diferentes maneras dependiendo de diferentes factores. 


F Tamaño 


El tamaño de una variable lo determina el tipo con el que se declare y 
la arquitectura para el que se genera el código objeto 32, 64 bits. En 
la siguiente tabla se muestran las implementaciones más comunes al 
respecto en 32 bits (No se tratarán los tipos float y double debido al uso 
de instrucciones de coma flotante, que están fuera del alcance de este 
curso): 
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Ancho en 
Valor mínimo Valor máximo 
жш з E | Е 














signed char 8 ЕТ] 127 
unsigned char 8 o 

short 16 32768 

unsigned short 16 o 

int з 2147483648 

unsigned int 32 o 

long 2 2.147,483,648 

unsigned long 32 o 4291967295 

long long “ 29223373036854775808 | 9223.372.036,854.775.807 
unsigned long long 64 ° 18.446,744,073,709,551,615 


lustración 16. Tipos de datos de 32h 





En arquitecturas de 64 bits, hay varias opciones y cada compilador opta 
por una: 


ا 


short 
int 

long. 
Tong long 
pointer 


16 16 16 16 16 
z з э 6 E 
2 32 64 ы 32 
NIA “ = “ 6 
32 32 ы 6 ы 


datos en 64 bits 





tipo: 





Estos detalles de implementación son especialmente interesantes de 
conocer a la hora de auditar código en busca de vulnerabilidades, ya que 
puede suceder que un código fuente sea correcto desde el punto de vista 
de la seguridad, y al compilarlo con dos compiladores diferentes, o con el 
mismo pero en arquitecturas diferentes, se introduzcan vulnerabilidades, 
por ejemplo, al desbordarse por arriba o por abajo el tipo de datos entero. 
Y de hecho este es uno de los problemas más comunes en vulnerabilidades 





de desbordamientos de buffer. 


En el siguiente ejemplo podemos ver variables declaradas con distintos 
tipos. Para ello se muestra un código fuente con diferentes tipos de 


variables locales y globales: 
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PREM 





Este programa de ejemplo simplemente declara una variable por cada tipo y 
las inicializa. 


F 186/32 bits 


La siguiente porción de código objeto en 32 bits, 





nerado para este 
programa, inicializa las variables locales: 


an 





entes variables, se han 





Para identificar de manera más directa las dife 
inicializado con valores claramente identificables en el código fuente. 
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Estas variables locales se almacenan en la pila, por ello se utiliza el registro 
que apunta a la cima ESP como base para calcular su localización. Esto 
lo veremos más claramente en el apartado de funciones. 





Se utilizan diferentes directivas de tamaño del lenguaje ensamblador 
para acceder a cada variable local. Como se puede ver en la tabla de la 
Hustración 16 el tipo char ocupa bits = 1 BYTE; short en realidad se 
traduce como short int y es por esto que ocupa 16 bits = WORD; int, long 
y long long son 32 bits — DWORD. El modificador signed y unsigned no 
se tendrán en cuenta hasta que se acceda a los límites de dichas variables 
o se realicen operaciones aritméticas o K 














Porotro lado podemos ver las variables globales, gvar? que son declaradas 
fuera de cualquier función e inicializadas. Este tipo de variables globales 
son almacenadas en una sección de datos. En el caso del compilador gcc 
lo denomina «data. Si no estuvieran inicializadas las hubiera almacenado 
en la sección denominada „bss. A continuación se consulta el contenido 
de las variables globales con el debugger, solicitando el contenido de 
memoria de la variable gvar! (comando: x/20x таг): 


Comparando con el ejemplo anterior es cuando se puede constatar 
la dificultad a la hora de reconstruir variables, ya que sin símbolos de 
depuración no hay ninguna manera de acceder a la variable en si. Habria 
que ir a la porción de código que maneja esa supuesta variable y ver con 
que directiva de tamaño lo hace para saber si se trata de uno u otro tipo, € 
incluso así, no sabremos qué tipo fue en el código fuente, sino que en esa 
porción de código ha manejado esa porción de la variable. 








En esta imagen se observan los valores de inicialización, correspondiendo 
con 1 (BYTE), 2 (WORD) y ADWORD) bytes de espacio cada uno, 
siendo rellenado con ceros a la izquierda el resto de espacio de la variable. 


Nótese como gvar3 y gvard siendo short, gvar3 ocupa 2 bytes mientras 
que gvará ocupa 4 bytes. Esto 
llevada a cabo por la optimización del compilador. Acceder a direcciones 
de manera alineada incrementa el rendimiento al no tener que hacer 
operaciones para calcular el espacio correcto. 


es debido a la alineación de memoria 





у 186/64 bits 


Para el caso de 64 bits se puede ver algo ligeramente diferente: 
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En este caso, además de la diferencia acerca de los 





istros, que se puede 


ver claramente en la siguiente imagen con el registro de ejemplo RAX 








Se observa que hay una nueva di 
64 bits = QWORD. 


setiva de tamaño para long long que son 


En cuanto a las variables globales, vemos como ahora las variables gvar7, 


gvar8, y g 


т АЕМ 32bits 


/ar9 ocupan $ bytes. 





En este otro caso con ARM, vemos algo bastante parecido a lo anterior, 
salvando las distancias en cuanto a la arquitectura, que modifica bastante 


la sintaxis, no solo en cuanto a los registros: 
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Aquí para realizar una asignación ha necesitado dos instrucciones, una 





para almacenar el literal a un registro (mov r3, nn) y otro para almacenar 
el valor del registro en una dirección de memoria apuntado por el registro 


r11 (también denon 





do fp o frame pointer) más un desplazamiento 





tivo (str r3. [r1], #а]). Сото se puede observar se 
utilizan también los mnemónicos strb y strh para almacenar un BYTE 
o un WORD en lugar de un DWORD. O incluso en el caso de gvar9, 
cuyo tamaño es QWORD como se puede ver a la hora de inicializar, que 





utiliza dos registros r3 y r4 para inicializar las direcciones de memoria 





а frl1, $36] y [r. 








En el caso de las variables gl 
al de 64 bits, solo que la única variable de 64 bits == QWORD, es руат 


Como se puede observar, вуа сый inicializada como 
Ox0000000000000099, aunque en la im: 


lobales, se puede observar un caso similar 








a no lo parezca, y es porque 


la memoria se gestiona en Little-endian, y el debugger trata de traducir 





los WORDS, por eso hay una mezcla. 


Para una mejor apreciación de estos detalles, es posible compilar el 
fuente como ensamblador, en cualquier de las arquitecturas, y ver más 
información sobre todo de las variables globales. Para ello utilizaremos 


el comando: 


98 REVERSING. INGENIERÍA INVERSA ORAMA 





Y podemos ver la declaración de las variables 
de ARM: 





obales, en concreto ahora 





Comprobando que efectivamente ocupa $ bytes = QWORD. 
F Alcance 


El alcance indica desde 






parte del pri pueden ser accesible 


indicarlo se tienen en cuenta donde han sido 





determinadas variables, para 
declaradas. En C, las variables pueden ser declaradas en cuatro lugares 
del módulo del progra: 





e Fuera de todas las funciones del programa, son las llamadas variables 





globales, accesibles desde cualquier parte del programa. 

+ Dentro de una función, son las llamadas variables locales, accesibles 
tan solo por la función en las que se declaran 

+ Como parámetros a la función, accesibles de igual forma que si se 
declararan dentro de la función. 

+ Dentro de un bloque de código del programa, accesible tan solo 
dentro del bloque donde se declara. Esta forma de declaración puede 


interpretarse como una variable local del bloque donde se declara. 
Esto solo está permitido a partir del estándar C99. 
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F Almacenamiento 


El almacenamiento ser refiere a la localización donde se almacenará la 


variable dentro del programa objeto: 





© static: indica que la variable debe ser accesible en cualquier momento 
del programa aunque no se esté ejecutando la función que lo declaró. 
Es decir, se utiliza para que una variable local perdure en el tiempo 


pudiéndose utilizar en cada invocación a la función, manteniendo su 








valor. Es por ello que se almacena en la sección de datos del binario, 


ya que, como se verá más adelante, las variables locales, se almacenan 





en la pila y estas se sobrescriben una vez se ha finalizado su ejecución. 


e register: asigna el valor a un 





stro del procesador. En el caso de 
gistros disponibles para su uso en esa zona 
modificador. Los accesos a 


que no dispusiese de ге 
de có 








se omitiria este 





tros 
son mucho más rápidos que a memoria. Es por esto que aunque el 
compilador trata de utilizar registros siempre que puede en la fase de 
optimización, el desarrollador puede querer decidir que una variable 
¡stro para mayor velocidad de cómputo. 








se almacene en un re; 


rencia de alcance entre las variables 





Aunque ya se ha podido ver la di 
locales y las globales, a continuación se muestra un ejemplo de código 
fuente que recopila los cuatro tipos de alcance y los dos tipos de 
almacenamiento comentados anteriormente: 
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Cuya salida al ser ejecutado es: 


En dicho código se pueden ver las cuatro zonas distintas donde se 
pueden declarar las variables que se han mencionado anteriormente. 





el apartado de tamaño hemos visto ejemplos entre el almacenamiento 
global (en la sección .data o „bss, dependiendo de si se han inicializado 
a no) y local (en la pila). El único matiz en este nuevo ejemplo es que, si 
utilizamos el modificador register, en lugar de utilizar una dirección de 


tro, tal y como se puede 





la pila o de la sección de datos, utilizará un r 
ver a continuación. 


F x86 32 y 64 bits 


El único matiz en este nuevo ejemplo (que debido a las pocas diferencias 
y 64 bits, se procederá a mostrar solo el ejemplo de 32 bits), 
ister, en lugar de utilizar una 
dirección de la pila o de la sección de datos, utilizará un registro, tal y 





entre 32 








es que si utilizamos el modificador res 


сото se puede ver en la siguiente ima 


La variable Ivar! inicîalizada con 0x11, se almacena en la pila (ya que se 








utiliza una dirección de memoria basada en el registro ESP que apunta a la 
cima de la pila), mientras que /var2 se inicializa en el registro EBX. Esto 
tro para el uso de esa variable en 
el ámbito de la función. Esto queda claro más adelante en el printf que 





hace que el compilador reserve ese г 





al empujar los argumentos en la pila para invocar a la función printf, se 


empuja EBX (main+60) 
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Esto quedará más claro en el apartado de las funciones. 


En el resto de código de la función main, se observa el buele for 


El alcance de las variables locales a un bucle, como es el caso de la 








variable ¡ usada en el for de nuestro código fuente solo se pre 
el código del bucle. En la implementación (main+84) se ve como se 
almacena en una variable de la pila /esp=0x1c] por lo que sería visible 





a toda la función, sin embargo, si tratáramos de acceder a ella desde 
fuera del bloque del for, nos daría un error de compilación por no estar 
declarada. 


Por último vamos a centrarnos en el modificador static que se utiliza para 
dar alcance global, pero restri 





endo el acceso solo a la función que lo 


declaro. Tal y como se puede ver en el código de la función foo(: 


Aquí se observa cómo se almacenan en el registro EDX una dirección de 
memoria de la sección «data (comando: objdump -h a.out), la variable b 
del código fuente 


La sección „bss, sección de datos no inicializados. Esto es así, porque no 
es hasta el bucle for que se inicíaliza por primera vez, tras haber ejecutado 
istro EAX un valor pasado 
umento, esto se sabe por qué se hace referencia a una dirección 





código. A continuación se almacena en el re; 
pora 

[ebp+0x08] cuya bass 
detalle en el apartado de las funciones. Es de 
fuente, y posteriormente se realiza la suma acumulativa (b += a; ) en 








es EBP, la base de la pila. Esto lo ve 





ir, la variable a del código 


foo+15 y foo+17 de la imagen anterior. 
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Almacenar una variable local en la sección bss, impide que el contenido 





de la variable local, se pierda al salir de la función y sobrescribirse los 
datos con las variables locales de la siguiente función invocada. Y esto 
permite almacenar información persistente a la ejecución del programa, 


pero de alcance restringido solo a la función 
ARM 32 bits 


Enlasig 





jente imagen se puede ver como el Ivar? se inicializa (*17=0x11) 
en una variable de la pila y /var2 en un reg 


la otra arquitectura 


En el caso del bucle, se observa como también se inicializa con el valor 451 
= 0x3 








stro, como en el ejemplo de 





y se almacena en la pila /111, 4-16), es decir en una variable local: 





Solo que como en el caso anterior, si se prei 





ende utilizar fuera del bloque 
del for el compilador g 





cra un error de compilación 


Por último, en el caso del modificador static en la función foo() se puede 


ver en el siguiente código, como se lleva a cabo la suma acumulativa en 





una variable cn la sección «data: 
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La suma se hace en fo0+28, si se observa hacia arriba, se ve como R3 
contiene un valor pasado por argumento (la dirección /717, 4-8] tiene 
como base R11 que en foo+4 obtiene el valor de la base de la pila). Y R2 
contiene la variable estática b, accedida en foo+16 y foo+20. Como se 
puede ver en foo+16 se obtiene el valor de /pe, 248], el 
el puntero de control, es decir indica la dirección que se está ejecutando. 
Esto nos dice que cuando ejecute esta instrucción, se almacenara en R3 











stro PC es 





el valor de la dirección #48 bytes adelante, en concreto en la dirección 
0x9250 
pero en el apartado de funciones, se verá como saber que esta función 
acaba en foo+68, y que el resto son datos, no instrucciones. Para ver los 





foo+72. En la imagen ant 





ior aparece como instrucciones, 


datos vamos a volcar esa zona de memoria: 


Se ve que almacena una dirección de memoria, que si consultamos la 


sección bss: 


Se comprueba que efectivamente estå ahi contenida: 
0x00024260 <0x0002432e < (0x00024260 + 0x00000114 = 0x00024374) 


Además de estos modificadores, existen otros como extern o const que 


a efectos de reconstrucción de código no son relevantes. Solo afectan en 





tiempo de compilación en cuanto a la política de acce 
Por ello no nos vamos a centrar en estos últimos. 


o de las variables. 





3.3 ARRAYS 


Ya conocemos los diferentes tipos de datos mås básicos que podemos utilizar 
y cómo se implementa cada una de sus modificadores o según donde se declare la 
Variable. Ahora vamos a pasar a un tipo de datos estructurados, los arrays. 


Un array es una variable donde cada elemento se almacena en memoria de 
manera consecutiva. Estos pueden declararse con varias dimensiones. Las cadenas de 
caracteres en C se declaran como un array unidimensional de caracteres, Los arrays 
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unidimensionales también son conocidos como vectores. Los vectores constan de 





una serie de variables del mismo tipo, denominados elementos o componentes del 


Otro tipo especial son los arrays de dos dimensiones, también conocidos 





como matrices. Al tener dos dimension 





simula una tabla accedida por la tupla 
[fila][columna]. Los arrays de tres o más dimensiones se acceden de la misma forma 


que las matrices dependiendo del número de dimensiones /n/][n2[n3)... [nn]. 





Las cadenas de caracteres son arrays unidimensionales, donde cada elemento 


es del tipo char. Se pueden inicializar elemento a clemento (7, “e”, Y, %, o", 10 





} finalizando con el carácter nulo, o todo junto entre comillas dobles así "texto de la 


cadena” donde el compilador agregará el carácter nulo al final. 








'ara poder analizar bien este tipo de variable, vamos a generar código objeto 






en distintas arquitecturas a partir del siguiente código fuente: 





rt varli] = { 555 


TSO ER 


gusi 


return 0 





” 18632 y 64 bits 


En este caso, 





al que en el anterior, la dife 
able. Simplemente el tipo de r 
la hora de invocar una función, que veremos 


encia entre arquitecturas 





istros y la utilización de 





es casi inapres 








registros como 





¡mentos a 
más adelante. 
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Este sería el código e 





Y este en 64 bits: 
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Vamos a centramos en el código de 32 bits, y vamos a comenzar 
identificando sobre la imagen, las distintas variables, para pasar a 


continuación a explicarlo más en detalle: 





La variable var] se inicializan como una lista de elementos, y es 





así cómo se implementa en el código, moviendo el valor a la dirección 
de memoria pertinente. Después, cuando se trata de acceder al elemento 





уаг2[1]. 
var2(1]/2 





se ve claramente cómo se accede directamente a la dirección 





de memoria para moverla un r ain+97). 





иго ( 


Enel caso de las cadenas de caracteres, vemos que var se comporta como 





varl y var2 mient 





s que var3 al inicializarla con una cadena de caractere 
entre comillas dobles, el compilador sabe que es una cadena de caracteres 
y utiliza valores de 32 bits (4 bytes), para copiar la cadena en la variable. 
Nótese como al final, agrega cl carácter nulo (1x0) para finalizar la cadena 


fuente no se ha incluido, esto lo 





de caracteres, mientras que en el cóc 
hace automáticamente el compilador al detectar las comillas dobles. 


Por último, vemos una inicialización especial en var, la utilizada con 





un puntero a memoria. Aunque los punteros los veremos más adelante, 





simplemente decir que 
а una cadena entre comillas dobles, el compilador guarda la cadena en 


declararse como puntero de tipo char, y apunta 


la sección .rodata en tiempo de compilación, de tal forma que ahorra 
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npo de ejecución a la hora de inicializar la variable. En 





main+146 se obtiene la cadena de caracteres de la dirección 0x080485 
que pertenece a la sección -rodata: 


Ya que 
0х8048568 <= 08048577 <= (0х8048568 + 0х1с = 0х8048584) 


F ARM 32 bits 


En esta arquitectura se obser 





como el comportamiento es parecido 





te son dife 
guiente cûdi 


ев. A continuación se 





aunque las instrucciones obvian 
identificaran las variables en el 





objeto: 





ШЫ 
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Como se puede observar, hace referencia a direcciones de final de la 
función maín. Concretamente main+160 hasta main+180, paro almacenar 
los valores obtenidos de la sección .rodata. Esto se sabe porque hace 
referencia a una dirección de memoria anterior a maín (main+24) y si se 
observa con el comando (obdump —x ./a.out) se ve que esa dirección es 
rodata: 


Para var lo que se hace es cargar la dirección de memoria de los datos de 
rodata en el registro R3 (main+24), apuntar cl registro R2 al final de la 
función main (main+20), donde se almacenarán los valores inicializados. 
Luego se almacenan en RO, RI y R2, los valores apuntados por el 
registro R2 (main+28) y se almacenan en R3 el contenido de RO, RI y 





R2 (main+32). 
El caso de las variables var2, var3 y var son prácticamente iguales que 
var], teniendo en cuanta que son datos diferentes. Sin embargo se pude 
ver como var4 al ser una cadena, se opta por copiar el contenido de la 
cadena en .rodata hasta las variables alojadas después de maín (main+108 
hasta main+116) 


3.4 PUNTEROS 





Ahora vamos a tratar un tipo de datos muy importante en C: los punteros. Este 
tipo de datos es especial en C y no se suele dar en otros lenguajes de programación. 
Los punteros son variables que apuntan a una dirección de memoria a modo de 
apuntadores a otras variables. 





Los punteros pueden apuntar a variables de cualquier tipo. Aunque el puntero 
еп si ocupa 32 bits o 64 bits, dependiendo de la arquitectura, el compilador esto lo 
tiene en cuenta para conocer la longitud del valor al que apunta. 





Los arrays son en realidad un puntero a la dirección base del array, es decir 
а [0] у pueden utilizar sintaxis de array o puntero indistintamente. 


Partiendo del siguiente código fuente: 
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observa que se han declarado una cadena de caracteres, y un par de 





variables e 





Una de ellas, un puntero a entero. A continuación vamos a ver las 


diferentes implementaciones: 


Р x86 32 y 64 bits 





En el siguiente código generado, vamos a identificar las variables 


definidas, así como las operaciones sobre ellas, en el código fuente 








Linea 10 
Linea 11 
Linea 13 


Lînea 14 
Linea 15 





Comenzaremos con la inicialización de la línea 5, como se puede ver, se 
obtiene u 





dirección de .rodata (se puede comprobar utilizando objdump 


como en casos anteriores ) y se almacena en la pila. 
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En la linea 10, asignamos al puntero p el contenido de la variable cadena, 
nótese que lo que se pretende es que apunte al contenido y no a la variable 
le cadena, el contenido de 





que lo contiene, ya que sì se apunta a la varis 
p sería la dirección de la pila, mientras que si se apunta a la cadena (que 
es lo que se pretende) el contenido de p es una dirección de la sección 
rodata. 


Luego pasamos a incrementar el punteo, como se puede ver en la 





imagen anterior, en el código de la linea 11; lo que se hace es sumar 1 


al contenido de la variable de la pila /ebp-0x8], esto deja constancia de 
que se incrementa su valor, lo si 


adelante del inicio de la caden: 





nifica que ahora p apunta a un byte mås 





Esto es especialmente útil cuando se 





quiere recorrer una cadena sin perder el apuntador que apunta al inicio de 





la cadena o región de memoria. 


En el caso de las variables enteras a y b el caso es más o menos parecido, 
sin embargo al incrementar b lo que estamos haciendo es incrementar su 


valor final, no el valor del puntero, dando como resultado 0x41414142. 
F ARM 32 bits 


Este caso particular: 





es bastante parecido al anterior, salvando las distancias en cuanto a los 


nemónicos y tipos de registro. 
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3.5 ESTRUCTURAS 


Las estructuras, son tipos de datos al 





parecidos a los arrays. La diferencia 





es que sus elementos pueden ser cada uno de un tipo diferente. Las estructuras 





existen solo en el len; 





jaje fuente, el compilador trata cada elemento como un objeto 
independiente sin relación entre los de 





mentos de la estructura. A continuación 
se muestran dos códigos fuentes 





yo desensamblado muestra como se accede a los 
elementos como si fueran variables independientes. Por un lado: 
ga 
struct basic ( 


txt LE] 
int valuel 


y(b1.txt 
OS 
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Y por otro lado el siguiente código: 


t 


txt [E1 
67 
vatui 

E 


strepy(txt 
valuel = 





En los dos códigos se observa cómo se accede a los elementos como variables 
locales dentro de la función. 


En este escenario es imposible reconstruir el código para que quede fiel al 








código fuente real, ya que no hay n tipo de información que ayude a relacionar 


las variables. En ocasiones, por el contexto del programa, es decir, conociendo el 





protocolo que se esté manejando, observando los mensajes de error o mensajes de 
estado, es posible relacionarlos, pero el código ensamblador no arroja ningún dato 


al respecto 


Hay un caso muy común que ayuda a poder reconstruir una estructura, y es 





¡cia a una función. En este caso, la función 
declara сото а 





n puntero a la estructura. Dentro de la función, al acceder a 


cualquier elemento, al estar dispuestos de maner 





ja, el compilador almacena 
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1а base еп un registro y utiliza este registro y un desplazamiento para acceder a los 





distintos elementos, como si se tratase de una cadena de caracteres o un vector. De 





esta forma sì podremos identificar diferentes estructuras analizando el códi 





objeto. 


A continuación se muestra un código fuente donde se invoca a una función 





pasándole por referencia una estructura, y se observarán los elementos para poder 


ver la implementación: 


IL 


КИ 
t vatuel 


basic_t b1, b2 


O) 





Cuyo código objeto dependiendo de la arquitectura se muestra a continuación, 
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Р x86 32 y 64 bits 


En 64 bits respecto al código fuente propuesto anteriormente, solo cambia 





el tipo de registro en cuestión. El siguiente código sería el generado para 
2 bits a partir del códi 





fuente anterior: 
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En la función main tal y como sucedió en los códigos fuentes del ejemplo 
anterior, se accede como variables locales, es decir, se utiliza el registro 
que apunta a la cima de la pila ESP. Sin embargo en la función foo se 





en el registro EBX el valor de la base de la estructura (/00+4) y 





después se accede a las elementos utilizando el registro como base y un 
desplazamiento para cada elemento (maín+25 hasta main+39). Si el tipo 
del elemento fuera diferente, por ejemplo short la directiva de tamaña, 
sería WORD, en lugar de DWORD. Esto sin duda ayuda a saber de qué 


tipo de datos es el elemento. 
ARM 32 bits 


Este ejemplo se puede ver igualmente, como se utiliza R4 para almacenar 
la base de la estructura, obtenida directamente del argumento de la función 
RO, como se puede ver en la instrucción foo+8, y luego se va accediendo 
a cada elemento actualizando el desplazamiento con la instrucción (STR 
valor, [base, #n]): 





Mientras que 


en la función main se accede de manera similar, pero 
utilizando el registro de pila SP: 
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Por último, simplemente comentar que existe otro tipo de datos 
denominado union que se define prácticames 
union) y la diferencia es que en lugar de ocupar 





ual que una estructura 








(cambiando struct por 
cada elemento espacios de memoria consecutiva, en la unión, todos los 
elementos ocupan el mismo espacio, es decir, para acceder a ellos se 
accede desde la misma dirección de memoria, solo que la directiva de 


espacio del código objeto será el indicado por ese elemento. 





El siguiente código fuente, muestra un ejemplo simple del tipo de datos 
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A aquí su código objeto, donde se observa que los accesos a variables, se 
hacen todos a la misma dirección /ESP+0x1C/ aún siendo de distintos 
tipos: 





Podemos ver la salida en hexadecimal: 


Donde se observa como se ha sobre escrito “BBBB" = 4 bytes por 
OXDEAD =2 bytes 


3.6 OBJETOS 


mentos no son solo los tipos 





Los objetos de C++, son estructuras cuyos 
elemento de dicha estructura pueden ser 





de datos vistos hasta ahora, sino que cad: 
métodos (funciones) y/o atributos (del tipo public, friend, ete... 


Los elementos de un objeto son procesados por el compilador como elementos 
normales de una estructura. Las funciones no virtuales son invocadas por el offset de 
la estructura, ya que el código de la función no está contenido en la estructura, solo 
la dirección al inicio de la función. Las funciones virtuales son invocadas a través 
de un puntero especial que apunta a la tabla virtual (Table) dentro del objeto. Las 
uier objeto, mientras que las funciones 





funciones públicas son llamadas por с 
privadas, solo pueden ser invocadas por el propio objeto. Esta privacidad de métodos 
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y atributos a efectos de reconstrucción de código no afecta. Solo afectan en tiempo de 
compilación en cuanto a la politica de acceso. En tiempo de compilación se muestra 
un error de compilación diciendo que no es posible acceder a ese método o atributo 
si se trata de acceder o invocar fuera de algún método de la clase. 


Para explicar de qué manera es posible relacionar ciertas variables en una 
estructura, y de esta forma reconstruir un objeto, es necesario definir un método que 





acceda a otros métodos y/o atributos de la clase- Es por esto que se definirá un método 
(función de una clase). Aún no hemos visto este tipo de estructuras, aunque hemos 
istros de cima y base de pila, no hemos profundizado en 
:mplo hará un uso sencillo de una función para 


poder mostrar cómo es posible identificar y reconstruir un objeto. 


hecho гей 





ncia a los reg 
ellas. Es por esto que el siguiente 





El siguiente código fuente inicializa variables locales a funciones y atributos 
de una clase: 





Ilustración 18. Código fuente de una clase simple 
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La estrategia para identificar el objeto es ver cómo se pasa como argumento 
de manera implícita un re 
método para acceder al resto de atributos y/o métodos de la clase. 


ístro que apunta a la base del objeto, y se utiliza dentro del 





Esto es así porque, para poder acceder a una estructura desde una función, 
umento de la función sea un 





es necesario pasarlo por referencia, es decir, que el arg 
puntero a la estructura que se pasa como argumento. Esto provoca que se utilice ese 
puntero para acceder al resto de elementos de la estructura. Cuando esta estructura 
es un objeto, este puntero se denomina (his, y se pasa de manera implicita, es decir, 
no hace falta definirlo como argumento, el compilador lo pasa automáticamente en 
un registro. En el caso de una estructura, sí es necesario pasarlo como argumento 
definiéndole el nombre que se desee. 


у 38632 y 64 bits 


En esta ocasión tampoco hay gran diferencia entre 32 y 64 bits. Las 








entes a la manera de invocar a las funciones, pero 
lle en otro apartado más 


diferencias son rel 








esto lo trataremos de manera separada y en 


adelante. 


A continuación vamos a ver la función maín que instancia una clase en el 
objeto ¢, para más adelante acceder a los diferentes atributos del objeto, 


а, Ь ус, asignándoles valores a los mismos: 





Como se puede ver, para acceder a ellos, se utiliza el registro EBP 
como base, ya que el objeto es una variable local y se utiliza la pila para 
almacenarlo. Es por esto, que no se diferencia en nada a una estructura 
local, o a tres variables enteras locales, tal y como se puede apreciar en 


el siguiente ejemplo: 
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F Variables locales declaradas e inicializadas independientemente: 





F Estructura local con elementos declarados e inicializados en forma de 
estructura: 








El resultado es idéntico para ambos códigos fuentes y para la porción de 
20 del código fi 
un objeto, es decir, que el contexto en cuanto a significado y relación a 


código maín=6 2 maín te anterior, donde se declara 
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alto nivel sobre las variables se ha perdido completamente, es solo una 
abstracción para el progi 
se trata de variables, una estructura o un objeto. 





mador. Esto es lo que hace imposible saber si 


Sin embargo, si observamos el método público foo_public() se puede 
observar una variación que nos ayude a identificar un objeto y no variables 
independientes: 





Si observamos foo_publ 





4 vemos cómo carga en EAX un a 





mento 





de función. Esto, como se verá más adelante en el apartado de funciones, 
se detecta porque se usa el 
positivo. Este registro es importante, porque a continuación se utiliza 
para inicializar unas variables usando £4X y un desplazamiento. Esto 





istro de base de pila y un desplazamiento 





indica que son variables relacionadas en función de una dirección base. 
Deber 








ar si se trata de una estructura o un objeto. 





Por otro lado, si vemos el có rvamos que la función no es 


declarada con ningún argumento: 








Por lo que ya nos daría una pista de que una estructura no puede ser. Si el 
compilador actúa así es para pasar el puntero this a la función invocada, 
e indicaría que es un método de un objeto. Sin embargo esto no podemos 


saberlo sin el código fuente, ya que si nos fijamos en el código objeto, se 





ve claramente cómo se pasa el valor del puntero como argumento: 
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Y no sabemos si ha sido el programador o el compilador. 





Identificación del objeto mediante el análisis de los métodos. 


Podemos encontrar otra manera de averi 





ar si se trata de un objeto, y es 





analizando la dirección del puntero base que se pasa рог те 


A 


SET 





Como se puede ver, el puntero apunta directamente a la primera variable 
local inicializada, esto relaciona dicha variable con la función, Si se 
pasase solo un puntero de esa variable a la función, el hecho de que dentro 
de la función se acceda al resto de variables conti 





1as a ese puntero, de 
igual forma que las variables locales de main, relacionan directamente 
esas variables contiguas, con un puntero base, mediante una estructura: 





En este momento ya sabemos que las variables y la función están 


relacionadas mediante una estructura; el hecho de que sea un objeto o 
una estructura poco importará, ya que, como hemos explicado respecto a 


código objeto, son lo mismo. 
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Y Identificación del objeto mediante el constructor. 
No obstante hay una forma bastante clara de identificar a un objeto, y 
es cuando se inicializan invocando al constructor. El constructor de una 
función, es una función especial, cuyo nombre debe ser igual que el de la 
clase y no devuelve ni 
con diferentes argumentos. Aquí tenemos un ejemplo del código fuente 





ın tipo. Se pueden declarar varios constructores 





anterior, al que se le ha agregado el constructor: 


рив11с( 





La única manera de invocar al constructor es mediante el operador new 


este reserva memoria para almacenar la estructura con el objeto y ejecuta 





el constructor correspondiente dependiendo de cómo se le haya invocado. 


Como nosotros solo tenemos un constructor, invoca a esta función. Como 





el operador new devuelve un puntero a la zona de memoria reservada, ¢ 


Libro encontrado en: 
eybooks.com 
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se declara como un puntero y los atributos y métodos se acceden con ~ 


en lugar del punto. 


Si observamos el rado en 64 bits: 





¡ente código objeto 








Esta utilización del operador new implementa el escenario de utilización 
de métodos, dond: cesario acceder con un puntero base, solo que 
ahora la situación sucede desde el inicio y sin necesidad si quiera de 





analizar los métodos. 


F Identificación del objeto mediante VTable 
La última manera que vamos a explicar sobre cómo identificar un objeto, 
ión de VTable, para saber que la estructura analizada es 





es la identific 








o y no una secuencia de variables o una simple 





efectivamente un ol 


estructura. 


Las VTables. son referenciadas por un atributo implicito del tipo puntero, 





es decir, no declarado por 
sado por el compilador, que apunta a una tabla con métodos 


1 programador, sino que es automáticamente 





(funciones) virtuales: 
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b 
Pointer to VTBL ] 


En programación orientada 2 objetos, las funciones virtuales se utilizan para 
implementar la sobrecarga de manera correcta. Cuando una clase hereda de 
otra clase base, se puede querer implementar un método ya implementado 
para modificar su comportamiento. De tal forma que 








por la clase bas: 





cuando se invoque el método, se ejecute el nuevo método implementado o el 





método de la clase base. Para permitir esto, estos métodos se deben declarar 
como virtuales y se almacenan en la VTable dentro del objeto. 


El sig 
virtual: 


fuente se ha declarado el método de la clase como 





jente cód 








nte: 





Y en el código objeto se puede ver lo 
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omáticamente un con: 





El compilador ha creado 
Dentro de 


el objeto (paso 3%). Y vemos cómo finalmente el e 


ictor en el paso 1 
la dirección de la VTable en 





este (paso 2°) se copia 








icnido de la VTable 





(paso 4") tiene un puntero a la fi tual foo_public (paso 5°). 








En el punto donde está parado el debugger <main(/+41> la instancia del 





objeto de I; 


ln Ûr 


Ох7Пе?70 = Sebp-0x20 — 05400780 VTable 
Dirección Valor 
0400780  0x40060c <AfyClass::foo_public(> 





clase MyClass, quedaría asi 





Охтїйїе?78 = Srbp-Ox1S 0А 
охтййїїе?7с = bp IA 02222722 
OXTAMMITe280 = Srbp-0x10 0533335333 
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Debido a esta utilización de funciones virtuales, es posible reconstruir 
el objeto a partir del puntero a la base utilizado por el compilador con el 
nombre this. Nótese que ha sido posible hacerlo sin llegar a analizar la 





función foo_public() que también hace uso de this. 


m caso sobre las funciones virtuales bastante 
común, donde se invocan mediante шп г 


Por último, cabe comentar 








istro cuyo valor es calculado en tiempo 
de ejecución. Esto es bastante importante a la hora de reconstruir el código, ya que 


dificulta en cierta medida su reconstrucción al necesitar analizar dicho registro en 









la dirección de la función a invocar. Esto sucede cuando 


se instancia una clase heredada de otra cuyo método o métodos son virtuales, tal y 


como se muestra en el código fuente del 





nte ejemplo: 
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La invocación al método foo_public() de la línea 40 y foo_public2() de la 
línea 42, se llevan a cabo mediante un salto basado en un registro, tal y como se 


puede ver en el siguiente código objeto: 





(CFG) que nos muestre el código como un todo, en forma de grafo cuyos nodos son 


los bloques básicos del código. Y con esto nos limita a la hora de revisar el código de 








manera estática y poder s jatos y/o de control 


Sin embargo, con lo aprendido anteriormente, podremos calcular el valor 
de EAX, sin necesid: 
se ha debido calcular dicho r 





de ejecutar código. Siempre que veáis un CALL reg, detrás 





en el cós tro. Para ese cálculo, el compilador 








parte del puntero thís y para obtener 


desplazamiento para lle; 


dirección de la VTable, y después modifica el 





ar hasta la función virtual en cuestión 
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Vamos a analizar las instrucciones 





¡atamente anteriores para tratar de 


obtener el puntero a la VTable y calcul 1 





remos el des; 





amiento para dar finalmente 
con la función a la que hará el salto el CALL RAX. Si observamos de nuevo la imagen 
anterior: 








En el primer bloque de сё, main+45> hasta <main+52>, se observa 





cómo se calcula el registro RAX. Las dos instrucci 





s siguientes es el arg 





mento 
que se pasa, en este caso solo rhis. Nos podria valer para obtener VTable, pero 
necesitamos saber luego el desplazamiento para determinar cuål de los métodos 
virtuales es. 


En el primer caso no se calcula ningún desplazamiento, mientras que en 





el segundo si hay un desplazamiento en la dirección <mai Nótese que los 


desplazamientos se llevan a cabo con instrucciones de sumas. 
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Ahora que ya sabemos que el primer caso es el método cuyo desplazamiento 
es 0 y el segundo caso es el desplazamiento $ de la VTable. Como estamos en 64 bits, 
iones de los 





hablamos de dos métodos contiguos. Ahora vamos a identificarlas diı 


métodos que se invocarán analizando el constructor: 





Esto permite saber que el primer CALL RAX invoca a <MyClassNew::f00_ 





public()> y el segundo a <MyClassNew::foo_publi 


Para confirmarlo, vamos a ejecutar hasta cada instrucción CALL y vamos a 


ver qué valor tiene 
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De esta forma queda confirmado que el método utilizado para reconstruir la 


VTable y analizar estáticamente el control de flujo es correcto. 


F ARM 32 bits 


En este caso, la estructura del código es bastante similar, salvando las 





diferencias entre tipos de r 





tros y arquitectura. Pero se utilizan los 
mismos mecanismos en los objetos, tanto a nivel de generación de 


VTables para las funciones virtuales, como las instanciaciones de objetos 





ico ya que en las fases de compilación 
etapa de generación de códi 


con o sin constructor. Esto es lóg 
el proceso tan solo se separa en la últim: 





intermedio a сб 





objeto, y se 





donde simplemente se traduce el cód 
realizan algunas optimaciones en este último código generado. 


Para no volver a repetir todos los pasos, vamos a mostrar tan solo los 
ejemplos relacionados con la VTable que contiene los ejemplos más 
básicos vistos en los otros apartados, 


A continuación se muestra el código fuente mostrado anteriormente: 
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Y el código objeto generado: 





Se observa cómo le pasa el puntero this al método en la dirección 





donde el código del método foo_public() es 
el siguiente: 
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Donde se observa cómo se accede a las variables locales y los atributos 





de las lineas 10-15 del código fuente. 


tra el código ой 





Por último, se mu eto del ejemplo más complejo de las 


VTables mostrado еп la Hustración 19- 








En las direcciones <+72> y <+112> se observan las invocaciones a 
métodos mediante un registro calculado y cómo se utiliza la suma para 
calcular el desplazamiento (<+96>), 

Así que si analizamos el código del constructor (<+32> cuya dirección es 
оха. 
de la misma, podremos obte: 





). y obtenemos la dirección de la VTable y mostramos los punteros 


las direcciones de los métodos utilizados 





en las llamadas mediante el 
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Con este profundo análisis sobre objetos es posible reconstruir el control de 
flujo de y de datos, de manera eficiente. 





ipo de tareas estå automatizado para entornos como IDA. También 
1 compilador de 





se recomienda la lectura de un gran artículo sobre este tema para 


Visual C en entornos Windows 





Y hitp:/howw.openree.org/articlesfall_view 


3.7 CUESTIONES RESUELTAS 


3.7.1 Enunciados 





1. ¿Qué tipo de dato se está inicializando con el valor 0x11 en la siguiente 
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2. ¿En qué segmento de memoria se almacenará el contenido de variable1?: 











а. stack 
b. heap 
e. bss 
d. data 
e. didata 

3. ¿En qué segmento de memoria se almacenará el contenido de variable1? 
a. stack 
b. heap 
с. bss 
d. data 
e. абша 


4. ¿En qué segmento de memoria se almacenará el contenido de variable1? 
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a. stack 
b. heap 
с. bss 

d. data 
e. абша 





¿En qué segmento de memoria se almacenará el contenido de variable1? 
¿Y el contenido de &variable1?: 








a. stack 
b. heap 
с. bss 

а. data 
e. didata 





6. ¿Cuál de los siguientes códigos fuentes ha g 
objeto? 


rado el siguiente código 
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AMA 


A а 
БЯ рн 


return Û return 


cadena 








la sis 
instrucción CALL RAX? 





guiente información, ¿qué método es invocado por la 
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MyClassNew::foo_public1() 


sE 





¢. MyClassNew::fo0_public3() 
d. MyClassNew::fo0_publica() 
e. _Znwm@pl) 


8. ¿Qué tipo de datos puede contener mûs valores “int” o ‘unsigned int'?: 


a. int 
b. unsigned int 

e. Los dos pueden contener el mismo número de valores. 
d. Depende de la arquitectura. 


9. ¿En arquitecturas de 32 bits, qué tipo de datos puede contener más valores 
“long long’ o ‘unsigned long long”?: 
а. long long 
b. unsigned long long 
e. Los dos pueden contener el mismo número de valores. 
d. Depende de la arquitectura. 


10.¿Qué múmero máximo de variables con modificador register pueden 
utilizarse en dentro de una funció 





20 
b. 4 
c. 16 
d. Depende de la arquitectura. 


3.7.2 Soluciones 


asa 
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3.8 EJERCICIOS PROPUESTOS 





1. Reconstruir el siguiente código objeto a código fuente en C 


DHORD PTR [ebp-9x8], OxB0484d0 








RECONSTRUCCIÓN DE CÓDIGO ll. 
ESTRUCTURAS DE CÓDIGO COMUNES 


Introducción 
En esta unidad se analizarán en profundidad las implementaciones de cada 


una de las estructuras de código más comunes еп С/С++, operadores, condicionales y 
bifurcaciones, y funciones. Este análisis se llevará a cabo en diferentes arquitecturas. 


Objetivos 

Cuando el alumno finalice esta unidad didáctica será capaz de identificar 
las estructuras de código más comunes en lenguaje C/C++. Le resultará posible, 
partiendo de un código objeto, identíficar diferentes estructuras y convertirlas de 
manera correcta a código fuente. 


4.1 ESTRUCTURAS DE CÓDIGO 





Conociendo los tipos de datos básicos y compuestos, que un compilador 
es capaz de implementar, podemos pasar a estructuras de código comunes, creadas 
por el compilador. Este tipo de estructuras de código sirven para llevar a cabo las 
diferentes acciones del programa, tanto de lógica de aplicación, flujo de ejecución, 
operaciones aritméticas, y otras. 


4.2 OPERADORES 








Los operadores aritméticos, lógicos, relacionados y de manejo de bits, son 
prácticamente reproducibles literalmente de código fuente a código objeto, debido 


142 REVERSING. INGENIERÍA INVERSA ORAMA 





a que los procesadores suelen tener una instrucción dedicadas a estas operaciones. 
Las más compl 
aquí por lo extenso y variedad de juego de instrucciones al respecto), así como 





jas suelen utilizar instrucciones de coma flotante (que no se tratarán 





operaciones de manejo de bits, como pueden ser los desplazamientos, operaciones 
lógicas como NOT, AND, OR, XOR. Todas estas operaciones suelen implementarse 
con una sola instrucción y es por ello que se deja en manos del lector generar una 
batería de ejemplos al respecto y llevar a cabo el análisis del código objeto para su 
correcta asimilación. En este curso se tratará de ver algunos de manera implícita en 
los diferentes apartados y ejemplos, como ha venido pasando hasta ahora. 


4.3 CONDICIONALES Y BIFURCACIONES 





Las condicionales y bifurcaciones son las estructuras de código que dotan de 
inteligencia al programa. Son las encargadas de tomar las decisiones y llevar a cabo la 
ejecución correcta de los distintos bloques básicos del código. A continuación vamos 


a explorar las diferentes sentencias de control y bucles permitidos en el lenguaje C 











Esta estructura ejecuta una porción de código si se cumple la condición. Esta 
condición será verdadera si la expresión es diferente de 0. Es decir, que cualquier 





cosa que se evalúe como distinto de cero será verdadero y si se evalúa como Û es 
falso. Esto es útil para evaluar los resultados de las ejecuciones de funciones usando 
jemplos de código fuente con 





el valor de retorno. A continuación se muestran varios 


su respectivo código objeto. 











SRAMA 


Capítulo. RECONSTRUCCIÓN DE CÓDIGO IL. ESTRUCTURAS DE CÓDIGO COMUNES. 143 


De donde se obtiene el siguiente código objeto: 


F x86 32 y 64 bits 





Este tipo de sentencias no se ven afectadas por 32 o 64 bits, por lo que se 


mostrarán ejemplos en 32 bits. 





Cada salto es provocado por un mnemónico (jmp, jbe, jle, je). Aunque es 


posible analizar los saltos tal y como se muestran en la im: 





-n anterior, 








precisamente para 
el código en modo de 


tipo de estructuras es bastante cómodo visualizar 





rafo. 








Para ello vamos a hacer uso de la herramienta de desensamblado más 
popular: IDA (Interacti 


comercial y para poder utilizarla sin coste all 





Disassembler). Esta potente herramienta es 





no es necesario utilizar su 
versión freeware 





Y hps:/hwww.hex-rays.comíproductsfida/support/download freeware 


shtml 
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Esta herramienta la estudiaremos con un poco más de detenimiento en 
temas posteriores. Si abrimos el binario con IDA, se verá lo siguiente: 





Como se puede observar, el número de bloques básicos coincide con 
los del código objeto anterior, marcados en rojo. Sin embargo con esta 
representación se ven más claramente. 


Las líneas verdes, indican el salto que se producirá si se cumple la 
condición. La roja si no se cumple y la azul un salto incondicional. 





F ARM 32 bits 


No hay gran diferencia estructural en esta arquitectura, las diferencias 
son en cuanto a la sintaxis, uso de registros y mnemónicos. El código 
fuente anterior, generaría este código objeto: 
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Se observa el uso de 





ıs macmónicos (b, bls, bl, ble, beq) que provocan 
el salto en cada bloque básico. 
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Si cargamos este código con IDA, veremos el siguiente diagrama: 


Donde también coinciden los bloques básicos con los marcados en rojo 


del código objeto anterior. 


Libro encontrado en: 
eybooks.com 
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F switchs 


Si se quiere comparar una variable con varios valores constantes, el lenguaje 





C provee de esta estructura que hace el código mås legible que sì se utiliza 


una lista de ¿f. El siguiente código fuente, muestra un ejemplo de uso: 





Este tipo de estructura admite una variable del tipo char o int, y una serie 
de constantes del mismo tipo que la variable. Dichas constantes no pueden 
repetirse dentro del switch. El defa 





It es opcional y puede no aparecer, así 
como los break de los case. La sentencia switch 





se ejecuta comparando el 
valor de la variable con el valor de cada una de las constantes, realizando 
la comparación desde arriba hacia abajo. En caso de que se encuentre una 
constante cuyo valor coincida con el valor de la variable, se empieza a 


ejecutar las sentencias hast 





encontrar una sentencia break. En caso de que 
no se encuentre ningún valor que coincida, se ejecuta el default (si existe). 


у x86 32 y 64 bits 
El códig 





objeto 





nerado en 32 bits seria el siguiente: 
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Cuyo gráfico obte: 





ido con IDA es el siguiente: 





Los switchs tienen una característica visual bastante peculiar que 
permite que scan identificados visualmente de manera rápida. Para verlo 
claramente vamos a introducir más constantes. Por ejemplo si tomamos 
este código fuente: 
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cont++ 


contes 


conta: 


cont++ 


conta: 


conta: 


conta: 


conta: 


cont++ 


conts+: 


conta: 


conta: 


conta: 


cont++ 


39 


cont++ 
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Cuyo código objeto es este: 
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En su visualización con IDA, se observa esto: 





Como se puede observar, es fácilmente identificable. Y se pueden extraer 
conclusiones, como el hecho de que al estar todos los bloques básicos 
alineados, es debido a que tan solo hace una comprobación. Para ver esto 
más en detalle, vamos a hacer zoom al bloque básico que deriva al resto: 








Se observa que se hace una operación aritmética para calcular el valor del 
registro EAX, y realizar el salto correspondiente. Si vemos el contenido 
de la dirección de memoria 0x8048500: 


Vemos cómo están almacenados de manera consecutiva las direcciones 
de cada bloque básico. Esto es lo que se conoce como switch table. Para 
poder hacer esto, se lleva a cabo la siguiente operación: 
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Ya que los case son constantes se obtiene el valor menor, se resta al resto 
e valor como desplazamiento para la switch table. De 
r entre 16 





y luego se utiliza e 


esta forma, con tan solo una comparación, es posible ese 








posibilidades diferentes. Esto demuestra la optimización de rendimiento 
h en lugar de if. 





que implica la utilización de 


F ARM 32 bits 
го fuente anterior, una parte del cûdi 





Para el cû 


siguiente: 


switch table 
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Se observa que al inicio hace la misma operación <+24> a <+36> resta 


0x41 a la variable y luego realiza un salto al bloque básico en cuestión 
mediante la actualización del registro de contador de programa, es decir, 
elre 


tro que apunta a la dirección de memoria que contiene la siguiente 





instrucción a ejecutar 


El mnemónico es /drls, almacena en PC el resultado de la operación 
PC+R3*4, donde R3 contiene el desplazamiento de la switch table. En este 





caso dicha tabla está a continuación <+40> indicada con un cuadro rojo. 
Como no son instrucciones, el debugger lo considera como instrucciones 
erróneas, pero si le decimos que nos la muestre como punteros lo vemos 
correctamente: 


F for 
Esta es la estructura de bifurcaciones más versátil. Permite inicializar las 
variables que van a tomar parte en el bucle, establecer las condiciones 
que deben cumplirse para continuar en el bucle y el incremento a las 
variables que intervienen en el mismo. En el siguiente código fuente se 
muestra un ejemplo genérico: 


Cuyo código objeto es el siguiente: 


у 38632 y 64 bits 
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Como se puede observar, se utiliza los saltos condicionales para 
permanecer en el bucle <main+41>, donde se incrementa la variable 
main+31> en cada iteración. 


Si observamos el código fuente con IDA, podemos ver este diagrama, 


característico de un bucle: 
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Donde la línea azul muestra cómo el flujo vuelve sobre sí mismo, hasta 
llegar a la condición que no se cumple y ejecuta el bloque básico final, 
apuntado con la flecha roja. 


F while — do/while 


Esta estructura de còi 





es una simplificación de lo anterior, y donde 
la sentencia no se encarga más que de comprobar que la condición se 
cumple para iterar dentro del bucle. 


La única diferencia entre 





estas dos estructuras es que while hace una 
primera comprobación de la condición antes de ejecutar el bloque de 
le primero ejecuta el bloque y comprueba la condición 
al final de este, lo que asegura que se ejecuta al menos una vez. 





código, y do/wh 








El siguiente código fuente, muestra un ejemplo de ambas: 





у 18632 y 64 bits 


El código objeto del códig 





fuente anterior es el siguiente: 
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do/while + 





Los saltos condicionales muestran la lógica del bucle. 








F ARM 32 bits 
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Si observamos el diagrama de flujo de esta estructura vemos esto: 





Enel di 





ama se aprecia claramente cómo uno compara € itera y el otro 


itera y compara. 


F break y continue 
Las sentencias de control break y continue permiten modificar y controlar 
la ejecución de los bucles anteriormente descritos. La sentencia break 
provoca la salida del bucle en el cual se encuentra y la ejecución de la 
sentencia que se encuentra a continuación del bucle. La sentencia continue 
provoca que el programa vaya directamente a comprobar la condición del 
bucle en los bucles while y do/while, o bien, que ejecute el incremento y 
después compruebe la condición en el caso del bucle for. 
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4.4 FUNCIONES 








Las funciones son un concepto matemático de abstracción de cálculos que 
permite abreviar la representación del cálculo de una operación, por su nombre. Esto 
es útil, por ejemplo, en casos donde el cálculo no es trivial y su desarrollo no aporta 
claridad al cálculo, por ejemplo con las funciones trigonométricas: sin(a), cos(a). 
tana). 


Las funcionesenC, permiten hacerel código perfectamente modular y facilitan 
la reutilización de código. Sin estas, no sería posible abstraerse adecuadamente, y a 
la hora de desarrollar o depurar el programa, habría que dedicar mucho esfuerzo en 
seguir el flujo del programa, además de incrementar las posibilidades de hacer saltos 
inadecuadamente y no restablecer el flujo de datos y control correctamente una vez 
se regresa del salto. 


Esta abstracción permite, porun lado, ofrecer un uso de ellas sin conocimiento 
de su implementación pero conociendo su especificación, es decir, el resultado de 
lo que hace con lo que se le proporciona. Por otro lado, permite la resolución de 
problemas por el método de divide y vencerás. Este consta en dividir los problemas 
en subproblemas más pequeños de manera recursiva hasta el punto en que los 
subproblemas obtenidos sean de solución trivial. Estas soluciones pueden resultar 
útiles en otros casos de manera genérica, y esto permite la reutilización de código, 
lo que optimiza el espacio, reduciendo las lineas de código al no tener que escribir 
lo mismo en varios sitios diferentes, y ayuda al mantenimiento del código, ya que 
si hay un fallo es suficiente con corregir la función en cuestión y no todas las zonas 
donde esta es utilizada. 


En programación orientada a objetos se explota aún más este concepto, 
pudiendo abstraer al desarrollador de lo particular para centrarse en lo general, 
y poder así utilizar clases polimórficas, donde dos clases diferentes puedan 
compartir un método con el mismo nombre, que dan el mismo resultado, pero cuya 
implementación sea diferente. 


Las funciones pueden ser declaradas con el modificador inline, de tal 
forma que en lugar de usar una función, se copia literalmente la función y se evita 
tener que realizar el salto, con su consecuente cambio de contexto. Esto es útil en 
determinados casos, por ejemplo con funciones de manipulación de arrays, donde se 
puede conseguir mayor rendimiento que si se utilizan funciones. 





Las funciones en C/C++ y métodos en C++ permiten ser invocados con un 
número no restringido de argumentos y devuelven siempre un tipo de datos pudiendo 
no devolver nada, en cuyo caso se define como void. 
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De manera genérica el funcionamiento de una función (o método, pero nos 
referiremos a función en ambos casos, ya que a efectos de código objeto no hay 
diferencia) se basa en realizar estos pasos: 


© Almacenar las variables a enviar a la función, si las hubiera en una memoria 
intermedia. 





Códigoque o Guardar la dirección de memoria de la siguiente instrucción, que debe 
aversta ejecutar al finalizar la función. 

© Saltar a la función. 

+ Almacenar el valor de retorno si lo devolviera y usarlo. 


a Reservar hueco en la memoria intermedia para poder trabajar con las 
variables locales. 
© Guardar el estado de los registros en una memoria intermedia 
© Recuperar los datos de la memoria intermedia, es decir, los argumentos de la 
función. 
Códigodela © Realizar las acciones propias de la función. 
función + Almacenar el resultado en un registro o memoria intermedia, según 
convención asumida por función y código que la invoca. 
© Deshacer el hueco reservado co la memoria intermedia. 
e Restaurar el estado de los registros desde la memoria intermedia 


e Saltar a la disección inmediatamente siguiente a la instrucción que invoca la 
función, almacenada en memoria intermedia. 


Para poder restablecer el control y los datos una vez se salta al código de 
una función se hace uso de una porción de memoria organizada cn forma de pila, 
formalmente denominada como LIFO (Last Input First Output). Cuando se almacena 
algo en esa memoria se dice que se apila un dato y al extracrlo de esa memoria se di 
que se desapila. Esto en x86 se realiza tradicionalmente con las instrucciones PUSH, 
POP. Para acceder a los argumentos, sin embargo, por motivos de optimización o 
convención, se pueden utilizar desplazamientos sobre los punteros a la cima o base 
de la pila sin modificar realmente el puntero a la cima hasta salir de la función 








A continuación se va a explicar gráficames 
pila al realizarse una llamada. 





la relación entre el código y la 
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3- Regreso de la 
de la función i 


la función funi 





n 





Mustración 20. Diagrama de uso de la pila por una función 





La ilustración anterior muestra el estado de la pila en los tres instantes de 
tiempo concretos en que se prepara para invocar a la función, en la invocación y 
en el regreso de la invocación. Las cajas representan casillas de memoria donde se 


cutar la función, realizar las acciones con 





almacena la información necesaria para 
los argumentos y volver al punto de origen con el resultado. Esta zona de memoria 








se denomina pila (stack) y se representa por las cajas en la ilustración anterior. 
Estas cajas simulan la acción de apilar y desapilar los datos, sin embargo se puede 
observar que al desapilar la información no se elimina, simplemente queda ahí y será 
sobrescrita por los siguientes argumentos o punteros a la cima y base de otra función 
al ser invocada 
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Cuando se producen invocaciones a funciones de manera anidada, los 
marcos de pila o stack frame (espacio entre la base y la cima de la pila) son apilados 
unos encima de otros, para respetar el orden de salida conforme se produzca. 


Esta manera de almacenar el contexto de la función facilita la utilización de 
funciones recursivas. 


Los argumentos pueden ser pasador por: 


F Valor: en cuyo caso, una vez se entra en la función, esta lleva a cabo las 
operaciones haciendo uso de una copia del valor pasado como argumento. 


Esto es equivalente a decir que ese argumento es de solo lectura. 





F Referencia: esto sucede cuando en lugar de pasar el valor de la variable, 
se pasa la dirección de dicha variable. Con ello es posible a través de un 
puntero acceder de manera completa a esa variable y poder manipularla, 
por ello seria equivalente a decir que el argumento es de lectura y escritura. 


El hecho de si se restaura el marco de pila (los punteros a la cima y la 
base) dentro de la función o fuera, está re 
reglas aceptadas por todos los desarrolladores, de tal forma que, sabiendo el tipo de 
convención usada, será posible utilizar la función cuya implementación desconoce 


egulado por convención, es decir, unas 





de manera correcta 


A continuación vamos a ver el código fuente de la Ilustración 20 para pasar 


después a ver su implementación: 
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F 18632 bits 


El código objeto del código fuente anterior es el siguiente: 


ОРА 





Utilizando un depurador, podemos ver el estado de la pila justo tras el 
prólogo de la función fun(), cuyo contenido a partir del registro ESP se 
observa como se muestra a continuación 





SRAMA 
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EN 


fund) 


Argumentos oe ta! 


Variables locale: 





Con el comando backtrace podemos ver esta misma información 
depurador, donde se leen los datos de la pila y los 





interpretada por el 
interpreta: 





En la Hustración 21 se ha mostrado toda la relación del código fuente con 
objeto, para que se pueda apreciar el uso de los punteros ESP y 
ar la pila, así como el uso de ESP como dirección base, 
esp+n]. valor) y EBP para 





el códi 





EBP para mane 





para empujar argumentos en la pila (mov 





acceder tanto a los argumentos (mov [ebp+n], valor) como a variables 


locales (mov [ebp-n]. valor). 
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En el código del prólogo, se observa cómo se almacena el valor EBP en la 

pila (push ebp), para ser restaurado al finalizar (leave), y cómo la base de la pila pasa 
esario para 

colocar la cima en un lugar donde haya espacio para las variables locales. Nótese que 





a ser la que era la cima (mov ebp, esp), para luego restar ESP el espacio ne 


la instrucción leave, se encarga de deshacer lo hecho en el prólogo, es decir: 


leave = mov esp, ebp 
pop ebp 


Por último se hace uso de RET, que devuelve el control a la instrucción 
siguiente a la llamada a la función. Dicha dirección se guardó en la pila al ejecutar 
la instrucción CALL. Esto es equivalente a cargar en EIP el valor que hay en la cima 
de la pila, es decir POP EIP. Sin embargo esta instrucción no existe en x86, ya que 
no se permite que las instrucciones POP, MOV modifiquen dicho registro. EIP es 
stro que apunta hacia la dirección que 
se debe ejecutar en cada momento, también conocido como PC (Program Counter) 














el contador de programa, es decir es el 





Como se puede ver, no se ha hecho uso de PUSH ni POP para apilar o 
г de accede a ellos con valores fijos de ESP 





desapilar los valores de la pila, en su l 
en cada marco de pila, o por decirlo de otra forma, en cada invocación a función. 


Esto es más eficiente que utilizar PUSH/POP, ya que 
modifican ESP cada vez que se cjecutan, consume ciclos de reloj lo que hace el 
código algo más lento. 





stas instrucciones 


Si 
de una función a la pila, se pueden utilizar estas dos opciones de compilación para 





e quiere forzar al compilador a usar PUSH para empujar los argumentos 


gee. El código fuente se puede volver a compilar con este comando: 


Pe 





O en la versión 4.9 de gec, simplemente con este comando, es posible 
forzarlo: 


MEE 








Y resultaría el siguiente código objeto: 
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Ahora los arg 
а la función. Sin embargo, ahora vemos cómo después de la invocación se ejecuta 





entos se empujan directamente en la pila, antes de invocar 





una instrucción de ajuste de 
esto se hace para compensar el movimiento de ESP, con los PUSH anteriores. Este 


pila, que antes no se había realizado en <main+53 


comportamiento viene establecido por la convención utilizada, en este caso de 





otras convenciones o convenios de llamada como 





manera implícita edecl. Existen 
sidcall, donde el responsable de restaurar la pila cs la función Vamos a definir la 
encerado 





función fum() como stdcall, para ver el código objeto g 
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Ya no se modifi 





P tras el CALL, esto lo hace la función mediante 
instrucción RET n, donde n ahora tiene un valor Ore que indica el valor que se le 
debe restar a ESP para res 





tablecer el marco de pila conforme estaba antes de que se 
invocara la función, justo lo que se le sumaba en la convención cdecl. 


Por último, se puede observar, como el compilador también utiliza las 
instrucciones PUSH/POP dentro de la función, si se ve obligado a utilizar los registros, 


gistros contienen información de la función que lo invoca, debe 





Como los re; 


(PUSH r se vayan a usar, y restaurarlos al acabar (POP 
reg) para que la función que lo invoca no pier 





uardar 
g) el valor de los r 





tros q 





ja la información almacenada en esos 
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registros. Si por ejemplo se utiliza el modificador register en unas variables locales, se 
fuerza a usar registros y esto requiere de PUSH y POP para almacenar y restaurar los 





sistros. En el siguiente código fuente, basado en el anterior, simplemente se agrega el 


modificador register a las variables locales de fiun(): 





Y el código objeto generado queda así 
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Aunque se han declarado las tres variables como register, al solo devolver z, 
la optimización del compilador ha optado por obviar los cálculos que no sean de esa 
variabl istro. En el si 





y es por eso que solo se utiliza ип г 





uiente ejemplo, veremos 





cómo se utilizan más re 





tros haciendo que el valor de retorno tenga relación con 
las tres variables locales. 


у 186 64 bits 


En este caso es todo bastante parecido, pero hay unas peculiaridades 
ecen la pena explicar en un apartado separado. Para detalles 
completos sobre esta arquitectura, se puede consultar el siguiente enlace: 





que mel 


4 htps://sofiware intel.com/en-us/articlesfimiroduction-to-x64-assembly 


Respecto a la invocación de funciones, hay ciertas modificaciones, por 
ejemplo,que en lugar de usar siempre la pila, se usan registros para los 
seis primeros argumentos. Esto se puede ver si modificamos el código 


fuente anterior para que la función tenga más argumentos: 





Hemos aprovechado, para modificar el valor de retorno, de tal forma que 
intervienen las tres variables declaradas como registro, Esto obligará a 





utilizar más registros y se podrá ver de qué manera lo almacena en la pila 


con PUSH/POP. 


También observamos cómo se han agregado cuatro argumentos más, y el 








código objeto sería el siguiente 
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Una vez que se han utilizado los seis registros (edi, esi, edx, ecx, r8d, r9d), 
el valor 0x10101010, se termina empujando a la pila con la instrucción 
PUSH, en lugar de utilizar un registro. 


También se ve como en fun() ahora se utilizan tres registros (uno por 
variable local) y es por ello que se deben usar más instrucciones PUSH: 
POP. 


F ARM 32 bits 


En el caso de ARM vemos como es algo más parecido a 186/64 bits, ya que 
registros (RO, RI, R2, R3). En la 


¡ente imagen, se ha compilado el código fuente anterior y se muestra el siguiente 


almacena los cuatro 





'gumentos de una función, en 








código objeto: 
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Como se puede observar, ARM utiliz 





varios registros, pero son de uso 
temporal, por lo que no necesitan guardarse пі restaurarse, ya que se 
asume que después de salir de una función su valor se ha sobrescrito. 


Por lo demás, y salvando las distancias entre mnemónicos. la estructura es 
similar a lo que ya hemos comentado. 
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4.5 CUESTIONES RESUELTAS 


4.5.1 Enunciados 


1. Identifica la estructura de código que se muestran en la siguiente im 





DHORD PTR [ebp-9x4], OX11111111 





if 
while 


for 


do/while 


swtich 


Identifica la estructura de código que se muestran en la siguiente im 











3 


b. 
4 
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if 
while 
for 
do/while 
switch 


Identifica la estructura de código que se muestran en la siguiente imagen: 


¿Qué tipo de convención se 





if 
while 
for 
do/while 


switch 


gue si la restauración del puntero de la cima 





de la pila se hace fuera de la función?: 


b. 
а 


fastcall 
stdcall 
thiscall 
edecl 
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¿Cuál de los siguien 
objeto? 


tes códi 


ros fuentes 





result 


return result return 


t result 


E 


return 


return result 








AMA 


nerado el siguiente código 





SRAMA Capítulo. RECONSTRUCCIÓN DE CÓDIGO IL ESTRUCTURAS DE CÓDIGO COMUNES. 1 


6. ¿Cuántos argumentos tiene la siguiente función?: 





¿Qué estructura de código se observa en la siguiente imagen”. 


E PTR [ebp-0xL],0x6 
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a if 
b. while 
c. switch 
4 


goto 


8. ¿Cuánto espacio se reserva para el marco de pila en la función que se 
muestra en la imagen”. 


1D PTR [ebp-0x4], 0x11 





a. O bytes 
b. 16 bytes 
с. 17 bytes 
d. No se puede determinar. 


9. ¿Cuánto espacio se reserva para el marco de la pila en la función que se 





muestra en la ima; 





a. 0x0 hytes 
b. 0x4 bytes 
€. 0x10 bytes 
d. 20 bytes 
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10.¿Cuántos argumentos se les pasan a la función <MyClass::fo0_public() 
que se muestra en la siguiente imagen”. 





al 
b. 2 
44 


4.5.2 Soluciones 


Ld 


9.с 


10.a 
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4.6 EJERCICIOS PROPUESTOS 





1. Reconstruir el siguiente código objeto a código fuente en C 


SOLCA 





2. Reconstruir el siguiente código objeto a código fuente en C 
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Dato adicional: 





Libro encontrado en: 
eybooks .com 
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Dato adicional: 





Cuestiones adicionales: 


e ¿Hay 





guna vulnerabilidad en el código anterior? 





+ ¿Qué modificaciones se pueden hacer para evitar problemas de 


seguridad? 











FORMATOS DE FICHEROS BINARIOS 
Y ENLAZADORES DINÁMICOS 


Introducción 


En esta unidad se explicarán los detalles característicos de los ficheros 
binarios PE y ELF. Sus estructuras intemas, detalles de implementación así como 
los detalles del cargador dinámico, implicado en el proceso de carga del fichero en 
memoria para su posterior ejecución por parte del sistema operativo. 


Objetivos 


Cuando el alumno finalice la unidad será capaz de interpretar un fichero 
binario sin más herramientas que un editor hexadecimal. El conocimiento adquirido le 
permitirá acceder a cualquier sección del fichero para su extracción y/o modificación. 
También será capaz de analizar cl proceso de carga dinámica, lo que le permitirá 
analizar el fichero binario desde antes de que este sea cargado totalmente. 


5.1 CONCEPTOS PRELIMINARES 








Cuando se lleva a cabo la compilación de un código fuente, y se obtiene el 
código objeto, en el caso de gee normalmente ficheros con extensión -o. Estos que 
contienen la traducción de código fuente a código objeto, no pueden ser ejecutados 
por el sistema operativo tal y como están. Esto es debido a que el sistema operativo 
necesita preparar el entorno de ejecución previamente a su ejecución. Para eso es 
necesario conocer bastantes detalles adicionales al introducido en el código objeto. 
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La reutilización de código, es un gran avance en temas de desarrollo de 
software. Poder usar funciones y código desarrollado por terceros, que hacen lo que 
deben y que, aunque no se conozcan los detalles de su implementación, sea posible 
utilizarlos para cumplir con acciones concretas de manera correcta, es sin duda una 
utilidad vital para cualquier software. Escribir un código desde cero, incluido la 
gestión de memoria, manejo de cadenas, gestión protocolos de red, de gestión de 
ficheros y demás, impediria poder desarrollar software avanzado o software básico 
en un tiempo razonable. 


Es por esto que se hace uso de librerías. Estas son ficheros objeto que exportan 
funciones para que puedan ser utilizadas por terceros, simplemente incluyendo 
una referencia a ellas en el fichero binario ejecutable, En enlazador dinámico es el 
encargado de crear el fichero binario ejecutable e introducir esta información, para 
que el sistema operativo al tratar de ejecutarlo, pueda obtener dicha información, 
localizar dichas librerías en el ordenador en el que se trata de ejecutar y de pasar el 
control finalmente al código objeto. 


Este proceso, aunque puede resultar trivial, conlleva la solución a varios 
problemas. Uno de ellos y más evidente, es el hecho de que cada librería pueden 
ser cargada en memoria en direcciones diferentes, por lo que hacer un salto a una 
función en concreto, cuando en un ordenador con un sistema operativo concreto 
está en una dirección y en otro ordenador con un sistema operativo idéntico esa 
misma librería se carga en otra dirección, es un problema a resolver por el enlazador 
dinámico y la información contenida en los formatos de ficheros binarios. 


Hoy dia debido a los sistemas antiexplotación, es especialmente importante 
poder localizar las funciones, ya que, ya no de un ordenador a otro, sino en un mismo 
ordenador cada vez que se reinicia o ejecuta de nuevo en el caso de Linux, es posible 
que las librerías se carguen en direcciones diferentes y esto, desde el punto de vista 
de unir funciones para poder ejecutar un software completo, puede ser un gran 
problema. 






Es importante también destacar la portabilidad entre distintas arquitecturas 
de hardware siempre y cuando mantengan el mismo sistema operativo. Esto es 
gracias a la interfaz binaria de aplicación ABI (Application Binary Interface) que 
describe la interfaz de bajo nivel entre una aplicación y el sistema operativo, entre 
una aplicación y sus bibliotecas, o entre partes componentes de una aplicación, 





Un ABI es distinto de una interfaz de programación de aplicaciones API 
(Application Programming Interface) ea que un API define la interfaz entre el código 
fuente y bibliotecas, por esto ese mismo código fuente compilará en cualquier sistema 
que soporte esa API, mientras que un ABI permite que un código objeto compilado 
funcione sin cambios sobre cualquier sistema usando un ABI compatible. 
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A continuación vamos a estudiar tanto los formatos de ficheros binarios, 
¡como los cargadores dinámicos utilizados por el sistema operativo para cada uno de 
ellos, que se encargan de analizar el fichero binario para proporcionar las librerías 
requeridas para su ejecución, así como de reservar memoria para cargar el proceso 
en memoria y pasarle el lujo del programa finalmente, 


Cabe destacar que este texto no pretende ser una guía detallada sobre el 
formato de ficheros, sino un enfoque práctico mediante el cual el lector pueda 
familiarizarse con los formatos de fichero binarios y cargadores dinámicos, desde un 
punto de vista práctico y no tan solo teórico como puede ser una guía completa de 
referencia sobre los mismos. 


5.2 BINARIOS ELF 





El formato ELF (Executable and Linkable Format) es un formato de archivo 
рага ejecutables, código objeto, bibliotecas compartidas y volcados de memoria. Fue 
desarrollado por Unix System Laboratories como parte de la ABI. En principio fue 
desarrollado para plataformas de 32 bits, a pesar de que hoy en día se usa en gran 
variedad de sistemas. 


Es el formato ejecutable usado mayoritariamente en los sistemas tipo UNIX. 
como GNU/Linux, BSD. Solaris, Irix. Existen otros formatos soportados en algunos 
de estos sistemas como COFF o a.out, pero ELF es sin duda el más usado. 


El formato COFF, también llamado Common Object File Formal, es una 
especificación de formato para archivos ejecutables, código objeto y bibliotecas 
compartidas, usada en sistemas Unix. Se introdujo en Unix System У, remplazando 
al formato aout usado anteriormente, y constituyó la base para especificaciones 
extendidas como XCOFF y ECOFE, antes de ser reemplazado en gran medida por 
ELE, introducida por SVR4. COFF y sus variantes siguen siendo usados en algunos 
sistemas Unix-like, en Microsoft Windows, en entornos EFI y en algunos sistemas 
de desarrollo embebidos. 


El formato a.out es un formato de archivo usado en versiones antiguas 
de sistemas operativos tipo Unix, para ejecutables, código objeto, y -en sistemas 
posteriores- bibliotecas compartidas. Su nombre proviene de la contracción de la 
expresión en inglés assembler output, de acuerdo a lo dicho por Dennis Ritchie en su 
trabajo The Development of the C Language: a.out sigue siendo el nombre de archivo 
de salida por defecto para ejecutables creados por ciertos compiladores/enlazadores 
cuando no se especifica un nombre de archivo de salida, aunque estos ejecutables ya 
no estén en el formato a.out. 
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El siguiente enlace contiene todos los detalles sobre el formato de fichero 
ELF asi como detalles del cargador dinámico utilizado por el sistema operativo para 
cargar el fichero ejecutable: 





Y huip://docs.oracle.com/cd/E19253-01/817-1984/chapteró-46512/index.html 


5.2.1 Formato de fichero 


Debido al gran trabajo de Ange Albertini (http://corkami.com) en cuanto a 
condensación de información sobre formatos de ficheros, se va a hacer uso aquí de 
estas imágenes, un resumen de los formatos de fichero para que el lector las conozca 
y pueda hacer uso de ellas, 


En este caso que nos ocupa, vemos el formato de fichero ELF: 





Dissected file 


Los ficheros binarios ELF pueden ser tres tipos de objetos: 


F Objeto reubicable: un fichero objeto reubicable tiene secciones que 
contienen código y datos. Este archivo está preparado para ser enlazado 
con otros ficheros objeto reubicables, para crear archivos ejecutables 
dinámicos, archivos de objetos compartidos u otro objeto reubicable 


Y Ejecutable dinámico: este tipo de fichero es un programa que está 
listo para ejecutarse. El archivo especifica cómo cl cargador dinámico 
debe crear la imagen del proceso en memoria. Normalmente depende de 
objetos compartidos que deben ser resueltos en tiempo de ejecución para 
crear una imagen final del proceso en memoria. 
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F Objeto compartido: un fichero de objeto compartido contiene código y 
datos que pueden ser enlazados. El enlazador puede procesar este archivo 
con otros ficheros objeto reubicables y ficheros de objetos compartidos para 
crear otros ficheros objeto. El enlazador es capaz, en tiempo de 
combinar este archivo con un fichero ejecutable dinámico u otros ficheros 





cución, de 





de objetos compartidos, para crear una imagen del proceso en memoria. 


Un fichero ELF está organizado en varias secciones. Una vez cargado en 





jones pueden ir juntas 





memoria, estas seci n varios segmentos de memoria, tal y 


como se puede ver en la siguiente imagen: 























Linking view Executon view 
ELF header ELF header 
Program header | Î Program header 

table (optona) table 
Section 1 
Segment 1 
Section n 
Sogment 2 
Section header Section header 
tablo tabio (optional) 





















código fuente incluya la utilización de 
funciones de librerías externas, para ver de qué modo se genera el binario ELF y cómo 
el cargador dinámico lee la información del binario para cargar la imagen en memoria, 
resolver las dependencias de librerías externas y finalmente ejecutar el código. 


Vamos a partir de un ejemplo básico 














El código fuente del ejemplo que vamos a analizar, es el siguiente 


Mustración 22. helloworld.c 





Libro encontrado en: 
eybooks.com 
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Compilamos el código en 32 bits: 


p 





ES loworld.e 





Y nos genera por defecto un fichero cuyo nombre es a.out. Apoyándonos en 
este documento, donde se detalla la estructura de los binarios ELF 





Y hitp:/idocs.oracle.com/ed/E19253-01/817-1984/chapterő-46512Andex-html 





F Cabecera ELF 


Vamos a analizar el fichero generado. Ya que lo primero que se encuentra en 


él es la cabecera ELF, cuya estructura para 32 bits es la siguiente: 





Vamos a analizar dicha estructura directamente del fichero 





siguiente comando: 


ET hd a.out | head 








De esta forma podemos mostrar la información en detalle con ‘readelf y 
literal en hexadecimal, con el comando “Ad” 
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Para una mayor claridad, vamos 





¡reste mismo código de colores, para 





relacionar la estructura del formato de cabecera ELF, (localizable en /usr/include 


elf:h) con la imagen anterior: 











La interpretación de e_íden 





la podemos extraer de las constantes del fichero 


Con esta información podemos localizar el resto de secciones accediendo a 





las cabeceras correspondientes, tanto las de pro, como las de sección. 
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AMA 


F SEGMENTOS 


Por orden de aparición en la. 





tructura anterior, vamos a acceder en primer 


(Program header) para ello volvamos a 





jugar a la cabecera de programa 


ver los datos de la cabecera del fichero ELF 








jecución, se refieren a s os y las características de cada 





En vista de 





uno de ellos se almacenan en forma de array de estructuras de cabecera 





de programa (Program header). donde vemos que la primera cabecera 





comienza en el offset 52 (inmediatamente después de la cabera de fichero 





ELF), que hay un total de ocho segmentos y que cada uno ocupa 32 bytes. 





Tal y como hicimos antes, partiendo de la estructura que define los 


segmentos 


В 
E 
Е 
Е 
& 
E 
Б 
Б 
E 
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Vamos a leer dicha información del binario con el comando readelf y 
luego lo comprobaremos sobre el volcado en hexadecimal el mismo 
fichero binario: 





Para volcar cl contenido en hexadecimal, utilizamos el comando 





remarcado en amarillo, que salta hasta el byte 52 (obtenido de la cabecera 





ELF) y muestra los 





guientes 0x20 (tamaño de un segmento) por $ 
ta ELF). Cada entrada 
hero donde se almacena el 


tificados en 






(número de s 





entos id 








contiene el offset o desplazamiento de 6 


contenido del segmento. 
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Se muestran los nombres de las secciones que lo contienen, habiendo 


varios casos en los que se contienen varias secciones. 





Nótese que ento OI cuyo offset es 0x30 y size 0x100, es 


ado con la constante PHDR 





precisamente el Program Header de 


(Process Header). También №6 





se que la sección 02 tiene como offset 
0x000000 y size 0x0000056c, esto indica que incluye los segmentos 00 
yor 


F SECCIONES 


Para poder interpretar las secciones, vamos a ver la cabecera de secciones 


ELF 


que se indica en la cabeces 








Mustración 23. ELF 
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Aquí podemos ver que la cabecera de secciones está localizada en el 
offset 1996 del fichero binario: que el tamaño que ocupa cada sección es 
de 40 bytes; que hay un total de 


contiene la tabla de nombres de secciones. 








1 secciones y que la sección número 28 


Partiendo de la estructura de la cabecera de sección: 


typedef struct 





Vamos a leer dicha información de 





inario con el comando readelf y 
luego lo comprobaremos sobre el volcado en hexadecimal el mismo 
fichero binario. Respecto al volcado en hexadecimal vamos a acceder al 
yl 
enido de la cabecera ELF, tal y 





996 del fichero para leer la tabla de seccione emos 40 bytes 





por sección. Dichos valores los hemos obt 





сото se puede ver en la Ilustración 23. 


Si quisiéramos acceder a la primera de las secciones, podríamos hacerlo 


de la siguiente forma 


$ hd a.out -s $((1996+40* )) -n 40 


A la segunda sección lo haríamos con: 


$ hd a.out -s $((1996+40* )) -n 40 


Y así sucesivamente hasta la sección 31 


$ hd a.out -s $((1996+40* )) -n 40 


O bien podemos mostrar la cabecera del fichero ELF más las 31 secciones 


uidas con el siguiente comando: 





$ геаде1# -8 а.ош&; Һа а.ош& -в 1996 -п $((40*31)) 
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Por motivos de espa lida, tan solo se han preservado 


las primeras secciones. Se ha pretendido separar por secciones en verde y 


dentro de cada sección los diferentes elementos en rojo. 
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El primer elemento, sh_name, es el offset sobre la sección de tabla de 
cadenas de nombres de secciones (sección 28 tal y como se indica en la 
cabecera ELF, cuyo nombre es -shstriah ), en este caso 0x000000 1b. Para 
poder extraer el nombre de la sección, vamos a acceder al desplazamiento 
Ox1b de la sección 28. Para ello deberemos acceder a la tabla de secciones 
(1996) más la sección 28 donde cada sección ocupa 40 bytes (40*28) 
al elemento sh_offset (que ocupa el desplazamiento 16 dentro de la 
estructura) y dentro de dicha sección (.shstriab), el desplazamiento Ox1b. 
Esto podemos hacerlo en varios pasos con el siguiente comando: 


$ һа а.ош& -в $((1996+40°28+16)) -п 4 


Obteniendo el si 
shstrtab): 


Accedemos a la sección 


iente valor (offset en el fichero binario de la sección 








ya que es la que se indica en la cabecera 
ELF que contiene los nombres de secciones, tal y como se puede ver en 
la Ilustración 23. El valor obtenido indica el inicio de la sección con los 
nombre de sección, Ox6c4, que coincide con la sección: 


Si accedemos al offset Oxlb, ve 
buscábamos para la 


De esta forma podemos acceder a cualquier sección, como por ejemplo la 





emos finalmente el nombre que 





хіба [1] que estamos analizando: 


sección -text que es la que contiene el código asm: 
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Y cuyo contenido se puede volcar así: 








Para comprobar el contenido podemos utilizar el comando objdump, para 


nsamblador contenido en binario: 





mostrar el código 








Como se puede observar, los opcodes marcados con el recuadro rojo 
coinciden con los valores del recuadro rojo de la imagen previa a la 


anterior. 
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ORAMA 


F Tabla de símbolos 





Podemos seguir mostrando código 





main() un poco más abajo de _start(), 





En cuyo caso la dirección Ox08048410 tiene la etiqueta <main>. Esta 


cadena de caracteres se extrae de otra sección denominada tabla de 
sección es -symiab. Realmente se sabe que 
tipo SYMTAB, el nombre podría variar, 





simbolos y cuyo nombre dí 








es la tabla de símbolos, por el 
sección contiene un array de estructuras 





pero el tipo debe ser ese. Dich 
Elf32_Sym que se define a continuación. 


typedef struct 
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Si vemos en las cabeceras ELF dicha sección aparece en el 





Y si analizamos los datos hexadecimales en esa dirección basándonos en 


la estructura anterior, vemos lo sig 





1e 


stiname,, „st value 





Vemos cómo cada línea contiene una estructura, y casi al final en el offset 


0x1084 aparece una 





tructura cuyo elemento st_value es la dirección 
de la etiqueta <main> visto con el comando objdump -S a.out y en la 
imagen anterior. 
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Para saber qué nombre tiene la ctiqueta localizada en la dirección 
0x0804841c, vamos al offset 0x00000213 (obtenido del elemento st_ 
name anterior) de la sección .strtab localizado en 0x10d4, y vemos el 
contenido de dicha dirección: 


Este ejemplo muestra cómo es posible moverse entre las secciones, 
resolviendo los nombres almacenados, asi como la consulta a la tabla de 
simbolos, útiles por múltiples propósitos. 

Aunque hay más peculiaridades con las secciones, se recomienda al lector 
analizarla detenidamente y leer la documentación 





¡cial al respecto para 


un mayor entendimiento. 


5.2.2 Cargador dinámico 


Al compilar el binario, se puede decidir si compilarlo de forma estática, para 
que introduzca el códi 
que el binario sea independiente y pueda ejecutarse sin necesidad de ninguna libreria 


de las librerías necesarias en el fichero resultante, de forma 








externa; o bien, como suele ser más normal, compilarsc de forma dinámica, donde se 
indican las referencias necesarias para que el cargador dinámico sepa qué funciones 


de qué librerías necesita el cdi 





y pueda cargar las direcciones correctas de los 
mismos en la imagen de memoria al ejecutar el proceso. Esto es lo más conveniente, 


ya que se pretende centralizar el código de forma que cualquier modificación por 





mejoras y/o correcciones de errores afecten a todos los binarios que hacen uso de 
ellos, sin tener que recompilar dichos binarios. Además del ahorro de espacio en 
disco, ya que no es necesario duplicar código constantemente. 


A modo de ejemplo, vamos a compilar el ejemplo de la Ilustración 22 de 
forma estática y de forma dinámica 


NS 
A 
SS 


—rwxr=xr=x l user user 4908 may 12 12:35 a.out 


RS E 
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Como se puede observar, la versión estática ocupa bastante más espacio en 
disco. Si tratamos de consular las librerias necesarias para ejecutar el binario: 


$ 148 a.out 
1їпшх-да®е.во.1 => (0х#7778000) 
A нүү УЕ ГУУ 


ИТҮ ҮҮ 
$ Laa static.a.out 


not a dynamic executable 





Vemos que en la versión estática, como era de esperar no necesita ninguna 


librería externa, 
F Acciones llevadas a cabo por el cargador dinámico 


a. Analiza la sección de información dinámica del binario contenida en 
la sección denominada (dynamic) y determina que dependencias son 
requeridas, 

b. Localiza y carga estas dependencias y analiza cada una de ellas para 
determinar si estas requieren de otras nuevas dependencias, a través 
de sus secciones de información dinámica. 

e. Lleva a cabo la reubicación de los objetos para preparar el proceso de 
ejecución. 

d. Pide cualquier función de inicialización proporcionados por las 
dependencias. 

e. Pasa el control a la aplicación 

E. Puede ser llamado durante la ejecución de la aplicación, para realizar 

cualquier función retardada vinculante. 

Puede ser llamado por la aplicación, para solicitar objetos adicionales 


con dlopen(), y se unan a los símbolos dentro de estos objetos con 
уто). 


Los procesos en Unix nacen de alguna de las variantes de la syscall fork(2). 
Este bifurca el proceso padre gen del proceso, una nueva entrada 
en la estructura proc_, y mediante exec(2) desplaza esta imagen para crear el mapeo 





y la estructuras en memoria para el nuevo proceso ejecutado. Tras este paso, y si este 
está compilado de manera dinámica, es invocado el cargador dinámico (Runtime 





Linker), en este caso /lib/ld-linux.so.2 (Mustración 24). para así poder efectuar el 





enlace con todas las otras librerías que el objeto requiera, como por ejemplo, libe 
so.6. Los datos del cargador están contenidos en el propio binario en la sección 


interp, como se muestra a continuación: 
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De manera práctica, podemos analizar un poco el cargador dinámico con 





el siguiente comando, que monitoriza las llamadas a las librerías en modo de 
notificación de mensajes de mayor nivel de detalle 


EE 





out 
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Tras analizar la configuración de ltrace, se ve las acciones tomadas sobre el 





binario: 





En primer lugar, y tras analizar la cabecera ELF, se ye como accede a PLT 


para enumerar las diferentes funciones necesaria: 





para la ejecución del binario. Y 
luego establece un punto de interrupción para poder monitorizar su ejecución y así 
poder obtener las variables y val 





ores de retorno, tal y como se puede ver, si quitamos 
los mensajes de DEBUG: 





De forma más detall 


uiente forma: 





la podemos analizar el proceso de carga dinámica con 
el comando strace de la si 








De esta forma se observa cómo comienza todo con un execve() tal y como 


se explicó previamente. Al invocar al fork(2) es р 





lo que se observa el mensaje: 


ORAMA 
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Luego vel 





mos cómo accede a varios archivos relacionados con el cargador 


dinámico, marcado en rojo. 


Se continúa (cuadro verde) abriendo el fichero libc.so.6 con apen() y 


seguidamente se accede a él con read(), para analizar las dependencias. Se observa 





). que sirve para reservar memoria en espacio del proceso, 





esto se hace para can 





'entos de la librería libc.so.6 en el proceso actual. 





Finalmente, tras varias 








iones de memoria del proceso, se 
ejecuta write(), función importada de libc.so.6, para mostrar el mensaje del programa 
а.ош. 


El cargador dinámico, per 





ite establecer unas variables de entorno, mediante 





las cuáles podemos interactuar para obtener información de depuración, Podemos 
utilizar variable LD_DEBUG para solicitar ayuda al respecto: 





Para el caso que estamos viendo, y para no abrumar al lector con demasiada 


información, vamos a utilizar simplemente la opción reloc, para visualizar el paso 





del cargador dinámico por las diferentes zonas del binario: 








Esta imagen muestra de manera resumida el proceso a grandes rasgos que 
lleva a cabo el cargador dinámico. 
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P Información dinámica en el fichero binario ELE 


Ahora vamos a analizar el fichero binario para obtener información 
dinámica del formato de fichero ELF. Para ello vamos a centramos 
primero en la sección -dynamic que contiene la información sobre la 
del proceso. Este contiene una lista de estructuras Elf32_Dyn 





definido como sigue: 





Y Con el comando readelf vamos a consultar la información dinámica 





contenida en 


Paralelamente al volcado del contenido en binario: 
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En la imagen se ha enmarcado en verde cada una de las 25 entradas de 
la sección, donde cada sección tiene dos elementos, separados por una 


linea roja. 


La primera entrada es de tipo NEEDED (0x00000001) 





Cuyo valor es 0x00000010. Esto no es más que el índice hacia la tabla de 


simbolos de la sección .dvnstr 


Es decir, el elemento número 0x10 de la tabla .dynstr. Esta tabla son cadenas 





mos acceder a la cadena 
le caso 0x10: 


de caracteres separados por NULL (1x0) у рох 





de caracteres que deseemos con el offset que lo refiere, en es 
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Ahora que ya sabemos las dependencias requeridas por el binario, vamos a 
pasar a determinar que funciones de esa libreria es necesario identificar. 


Para esto es necesario analizar las secciones GOT (Global Offset Table) y PLT 
(Procedure Linkage Table). La tabla GOT 
de una librería utilizada en el có 





serva espacio para cada función requerida 
dor dinâmico, cuando tiene la libreria 





o, y el cas 





compartida cargada en el proceso, escribe en dicho hueco la dirección de memoria final 
de la función. PLT forma parte del código y son unos esquemas de código (stubs), es 
decir, instrucciones en ensamblador, a donde saltará el programa cuando se invoque 
a dicha función para que desde aquí se salte a la dirección almacenada en GOT por 
el cargador dinámico. Estas porciones de código se encuentran en la sección ple y se 


pueden mostrar como código en: 





blador con el comando (objdump -S a.out): 





Donde (08049674 contiene la dirección final de printf en la libreria lihe 
30.6. El Mujo de ejecución sería como en la imagen siguiente 
aout mesos 


== 





























ORAMA Capitulo 5 FORMATOS DE FICHEROS BINARIOS Y ENIAZADORES DINÁMICOS 207 





Nótese que PLT contiene código ejecutable que realiza el salto a la dirección 
que contenga GOT. 


Se deja en manos del lector recorrer estas secciones para ver de qué manera 
están formadas y practicar con el manejo e interpretación de la tabla de símbolos y 
cadenas. 


5.3 FICHEROS BINARIOS PE 








El formato PE (Portable Executable) es un formato de archivo para arc! 
ejecutables, de código objeto, bibliotecas de enlace dinámico (DLL), archivos 
ejecutables (EXE), y otros usados en versiones de 32 bit y 64 bit del sistema operativo 
Microsoft Windows. El término portable, refiere a la versatilidad del formato en 
"numerosos ambientes de arquitecturas de software de sistema operativo. Al igual 
que los ficheros ELF, este formato PE contiene unas estructuras que encapsulan la 
información necesaria para el cargador dinámico de Windows, y poder así ejecutar 
el código en cualquier máquina con esc sistema operativo. Esta información 
incluye las referencias hacia las bibliotecas de enlace dinámico para el enlazado, la 
importación y exportación de las tablas de la API, gestión de los datos de los recursos 
y los datos de almacenamiento local de subprocesos (datos de TLS). En sistemas 
operativos basados en Windows NT, el formato PE es usado para EXE, DLL, SYS 
(controladores de dispositivo), y otros tipos de archivo. La especificación Extensible 
Firmware Interface (EFI) indica que PE es el formato estándar para ejecutables en 
entornos EFI. PE es una versión modificada del formato COFF de Unix. Además, 
PE/COFF es un nombre alternativo en el desarrollo de Windows. 








En sistemas operativos Windows NT, actualmente PE soporta los conjuntos 
de instrucciones (ISA) de 1A-32, 1A-64, y x86-64 (AMD/Intel64). Previo a Windows 
2000, Windows NT (y por tanto PE) soportaban los conjuntos de instrucciones 
MIPS, DEC Alpha y PowerPC. Ya que PE es usado en Windows CE, este continúa 
soportando diversas variantes de las arquitecturas MIPS, ARM (incluyendo a 
Thumb), y SuperH. 





5.3.1 Formato de fichero 


Como en el apartado anterior, para estudiar el formato de fichero vamos 
a hacer referencia a este gran resumen visual sobre el formato de fichero de Ange 
Albertini (h1p://corkami.com) para el formato PE: 
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SMPLEEXE 


PE” a windows executarle walkthrough -= 
DISSECTED PE 


Aunque no es posible visualizarlo completamente debido al espacio, si se 
observa claramente las secciones principales. 


La especificación oficial del formato de fichero binario PE se puede consultar 
visitando cl siguiente enlace: 
Y htips://msdn-microsoft.com/en-ushwindows/hardware/gg:463119.aspx 
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Como se puede ver en este documento, un binario PE se compone de las 
siguientes partes 


Base olmage Header 





MS-DOS 2.0 Compatible 
EXE Header 





Unused 





OEM denier MS-DOS 20 Secion 
OEM Iniomaion |} gms Dos 


Compatibilty, oniy) 
Offset to PE Header 





MS-DOS Z0 Stub Program 
aná 
Relocaton Table 
Unused 
PE Header 
(Aligned an &-byte boundary) 











Section Headers 





import Pages 
impor formaron 
Ergon formaron 
Base telocatons 
Resource formation 














A continuación vamos a analizar cada una de ellas para conocerlas más en 
profundidad y entender cómo trabaja el cargador dinámico con ellas. 

Para poder trabajar correctamente vamos a hacer uso de una gran librería de 
análisis de ficheros de formato PE escrita en Python, PE File. Se puede instalar desde 


los repositorios oficiales con: 
hon- 


$ sudo api ES 





O bien desde el repositorio de Python, que suele estar más actualizado: 


$ вайдо рїр їавїа11 ребїе 


Ahora vamos a compilar nuestro ejemplo de la Ilustración 22, que tan solo 
muestra un mensaje por pantalla. Para ello podemos compilarlo desde Linux con 
Mingw, o bien utilizar cualquier otro compilador desde Windows, como Visual 
Studio (ve) o DevCpp. Aquí se ha optado por usar Mingw como cross-compiler соп 
gcc, para mostrar esta posibilidad. 
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Para dar un enfoque más didáctico, vamos a utilizar un recurso, publicado 
en Internet, que hace uso de PE File. Esta página web, permite subir ficheros 
binarios PE, y genera una salida con la interpretación de los datos del fichero PE, de 
manera estructurada en formato HTML. Si subimos el fichero a.exe que generamos 
anteriormente, veríamos algo así 


[IMASE_NT_HEADERS] 
Signature: 94550 





NMAGE_FLE_FEADER] 
Machine 14C 

Numberorsectors: oxe 

TimeDateStamp Qx5553C208 [Wed May 
13212843 2015 UTC] 
PoimerToSymboTable 0x3200 
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NumberOfSymbols Ox16C 
SizeOOplonalHeader: ONEO 
Characteristics: 0x107 

Flags IMAGE_FILE_328IT_ MACHINE, 
IMAGE FILE EXECUTABLE IMAGE, 
IMAGE_FILE_LINE_NUMS_STRIPPED, 
IMAGE_FILE_RELOCS_STRIPPED 


OPTIONAL_HEADER 





[IMAGE_OPTIONAL_HEADER] 
Magic: 0x108 

MajorLinkerVersion: 0x2 
MinorLinkerVersion: 0x38 
SizeOCode: Ox600 
SizeOflnitializsdData: Ox 800 
SizeOfUninitializedData: 0x200 
AddresO1EntryFoint 01130 
BaseOfCode: Ox1000 

BaseOfData: 

ImageBase: 0x400000 
SectionAlignment- Qx1000 
FileAlignment 0x200 
MajorOperatingSyatemVersion: 0x4 
MinorOperatingSystemVersion: 0x0 
MajorimageVersion: 0x1 
MinorimageVersion: 0x0 
MajorSubsystemVersion: 
MinorSubeystemVersion: 
Reserved: 0x0 
SizeOtimage: OxF000 
SizeOfHeader 0:400 
Check Sum: 0x1494D 
Subsystem: O3 
DilCharacieristics: Ox0 








SizeOfStackCommit Ox1000 
SizeOtHeapRenerve: Ox100000 
SizeOfHeapCommit 0x1000 
LoaderFlags: 0x0 
NumberOfRvaAnd Sizes: 0x10 
DilCharacieristies 
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Misc_PhysicalAddress: OXSFO 
Mis_VirualSize: OXSFO 
VirtualAddress: 01000 
 Size0fRawData: 0x600 
FointerToRawData: 0x400 
Pointer ToRelocations: 0x0 
PointerToLinenumbers: 0x0 
NumberOfRelocations: 0х0 
NuMberOfLinenumbers: 0x0 
Characteristic 0x60500020 

Fags: IMAGE_SCN_ALIGN_IBYTES, 
IMAGE_SCN_ALIGN_4BYTES, 
IMAGE_SCN_ALIGN_MASK, 
IMAGE_SCN_ALIGN BYTES, 
IMAGE SCN_ALIGN_4096BYTES, 
IMAGE SCN_ALIGN_32BYTES, 
IMAGE_SCN_ALIGN_16BYTES, 
IMAGE_SCN_CNT_CODE, 
IMAGE_SCN_ALIGN_8192BYTES, 
IMAGE_SCN_ALIGN_256BYTES, 
IMAGE_SCN_MEM_EXECUTE, 
IMAGE SCN_ALIGN_64BYTES, 
IMAGE SCN_ALIGN_2048BYTES, 
IMAGE SCN_ALIGN_1024BYTES, 
IMAGE_SCN_MEM_READ 
Entropy: 5 472351 (Min=0 0, Max=8 0) 


[IMAGE_SECTION_HEADER] 


Més_VirualSize- OX2C 
VirwalAdaress: 
SîzeOfRaw Data: 0x200 
FointerToRawData: OXA00 
FointerToRelocations: 0x0 
PointerToLinenumbers: 0x0 
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IMAGE_SCN_MEM_READ 
Entropy:0-101910 (Min=0.0, Max=8.0) 





[IMAGE DIRECTORY_ENTRY_EXPORT] 
VirtualAddress 0x0 

Size 0x0 
[IMAGE_DIRECTORY_ENTRY_IMPORT] 
VirtwalAdaress 0x5000 

Size 0x218 
[IMAGE_DIRECTORY_ENTRY_RESOUACE] 
VirtualAddress 0x0 

Size 0x0 
[IMAGE_DIRECTORY_ENTRY_EXCEPTION] 
VirtualAdaress 050 

Size 0x0 
[IMAGE_DIRECTORY_ENTRY_SECURITY] 
VirtualAddress 010 

Size 0x0 
[IMAGE_DIRECTORY_ENTRY_BASERELOC] 
VirtualAddress 050 

Size 0x0 
[IMAGE_DIRECTORY_ENTRY_DEBUG] 
VirtualAddress 0x0 

sire oxo 
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OriginalFirstThunk: 0x5040 
Characteristics: 0x5040 

TimeDateStamp: 0x0 [Thu Jan 1 00:00:00 
1870 UTC] 

ForwarderChain: 0x0 

Name: 0x51D0 

FirstThunk: OX508C 


KERNELS2 dll ExiiProcess Ord[156] 
KERNELS2 dll GetModuleHandleA 


opa] 
KERNEL32 dil GetProcAddress Ord[364] 
KERNEL32 dli SetUnhandledEsceptionFi ler 


oraras 


[IMAGE_IMPORT_DESCRIPTOR] 
OriginalFirstThunk: 025058 
Characteristics: 0x5058 

TimeDateStamp: 0x0 [Thu Jan 1 00:00:00 
1970 UTC] 

ForwarderChain: 0x0 

Name: 01520C 

FirtThunk: OX50M4 


msvcrtll._getmainaras Ora[89] 
төеп ай _р_ епп ОБО] 
mevertdll—p_fmode OralB2] 
теат! з арр уре Оті] 
msvertall_cexitOrdl121] 
mevertdll_iob OrdP331 
msvertdll._onexit OrdfB50] 
mevert dil_setmode OrdB88] 
mert dil ateit Ord40] 
mevertl. print OrdB39] 
ımvertdll signal Ord B56] 
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Las zonas de las secciones y directorios se han cortado por falta de espacio. 


F Cabecera PE 


Las estructuras de las diferentes secciones del fichero, vienen definidas 





en winnt.h. Los primeros bytes del fichero corresponden a la estructura 


IMAGE_DOS_HEADER definida así 





















typodof struct _THAGE_BO6 HEADER { 
WO € magic; Heade e 
мао cos 1 
NRD ссср а 
л т 
мао рафа e a ho 
WRD Eninalloc; е ег 
МОО Саха ос: = 
кояр тт 2 
мр ja 
NORD A 











} IMAGE _DOSHEADER, *PIMAGE 005 НЕ) 





Donde el primer elemento es el característico “MZ” inicial de los ficheros 
PE. Esto según se dice, es debido a Mark Zbikowski, uno de los empleados 


más antiguos de Microsoft y diseñador del DOS executable fileformat, es 








decir, el responsable de que esta sección continúe existiendo y lleve sus 
iniciales. 


Si obtenemos los primeros bytes del binario a.exe y lo interpretamos, 


obtendremos que: 
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El mensaje que aparece se estableció con la entrada de las primeras 
versiones de Windows para que se mostrara dicho mensaje al ser ejecutado 
el binario por línea de comandos. 


Sin duda, el elemento más importante de esta estructura es e_/fanew, 
que apunta al offset del fichero, donde comienza la cabecera PE cuya 





typedef struct IMAGE } 





DWORD Signature; 
IMAGE FILE HEADER 
IMAGE OPTIONAL + 

} IMAGE NT_HEADERS32, *PIMAGE_NT_HEADERS32; 





En nuestro caso, como se puede ver en el volcado hexadecimal anterior, 
la sección IMAGE_NT_HEADERS está en el offser 0x00000080. Si 
visualizamos datos a partir de este offset, aplicando el elemento DWORD 
Signature, vemos 


Y posteriormente, si aplicamos la estructura IMAGE_FILE_HEADER tal y 


como se define aquí: 


typedef struct IMAGE i 
WORD Machine 
WORD 
DWORD Ti 
DWORD 
DWORD 
WORD 
WORD 

} IMAGE_FILE HEADER, 





E HEADER { 


Vemos los siguientes datos: 





Nótese que se piden tan solo los 0x14 bytes, que son la suma del tipo de 
los elementos de la estructura (WORD=2 bytes, DWORD=4 bytes -> 4*WORD + 
3*DWORD = 4*2 + 3*4 = 0x14) 
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F Machine indica el tipo de la máquina. En el caso de la plataforma Intel 
este valor equivale a la constante: 


iidefine IMAGE FILE MACHINE 1386 ӨхӨМАс 
F NumberOfSections contiene el número de secciones del fichero. Esta 


variable es importante cuando se quiere añadir una sección nueva al 
fichero. 





V TimeDateStamp se usa para almacenar la hora y fecha de creación del 
fichero. 


F PointerToSymbolTable y NumberOfSymbols, para tareas de depuración. 
F SizeOfOptionalHeader indica cl tamaño de la estructura OptionalHeader. 


Y Characteristics, indica características del fichero, por ejemplo si es un 
EXE o una DLL. 


La última parte de IMAGE _NT_HEADER, en concreto la estructura 
IMAGE_OPTIONAL_HEADER3), sc define con la siguiente estructura: 


padel struct 2 CTE MES Y 








ГА 1) 
ВМР Majerineriersin; 

BYE Mnorineriersion; 
Тито гооо 

ТМРО шайт алайа 
шко азала, 
тя дег еекрйЕг гуд; ө 
ТИКО засо, 

пиво бана 








ге мт абон Бада: +, 


Duro Inageease; 
тағо заа аа 09 аид 
СИКО ашла 
ID parana, 
NORD. Manortperatings)otentersimne 
MOO Major Tnageversaon: 

Шар perrera, 

Mo mjorsbsystemersion; 27 0с 
MED nora 

DAL tenerse 
Боя 

пиво алана: 

DWORD Chec ksen; » ano 
геа 

мояд оазе; 

Тын гайы уйан 

пано заанен 

тко этермариезетуе: 0% ан 
DMR S1200 Hapa 

OMED Loader flags 

сито азата: 

ТЕ Гит. Г#ЕСПЕТ биги өстшсу[ттрдЕ ROO DOECTIRT_ ENTRIES]; ° Ons + 
r es 

Y nac PTA, HEADERS, PDA OPTICAL ETE 
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Elespacioqueocupaesta, venia definidoenla variable SizeOfOptionalHeader 
(OxE0 en nuestro caso) por lo que vamos a leer ese número de bytes a partir del offset 
Ox84+0x14 = 0x98: 








Uno de los elementos 
AddressOfEntrypoint, posteriormente denominado Program E 





ás importantes de esta estructura ех 
try Point, que es una 








RVA de la primera instrucción del código de programa que arrancará su ejecución. 


Y por otro lado ImageBase, que representa la dirección de carga preferida 
para el fichero PE. El valor establecido por defecto es 0x00400000, 





Su efecto lo podemos comprobar al abrir el binario compilado con un 
debugger. Para ello vamos a abrirlo con uno basado en OllyDbg, de la empresa de 
seguridad Immunity Inc. Es gratuito y permite interacción mediante scripts escritos 
en Python. El enlace de desca 





4 htp://debuggerimmunityinc.com/ID_registerpy 


Si procedemos a abrir el binario con este debugger, veríamos lo siguiente 


ыл 
TE س‎ тыз эы 

a ЧНШЗ теат уверкъзг 
TRA 
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Como se puede ver en la imagen, el debugger está en parada justo 
en la dirección 0x00401130, cuya dirección está nombrada como 
ModuleEntryPoint. 


En los sistemas operativos multitarea, los procesos no se ejecutan en 
paralelo, o al menos, no del todo. La cuestión es que el flujo de ejecución 
va saltando de un proceso a otro, según de planificador de tareas del 
sistema operativo. Esto permite que varios procesos puedan tener la 
misma imagen base, sin sobrescribirse unos con otros. En el caso de que 
al tratar de cargarlo esta dirección de memoria ya estuviera ocupada, se 
le asignaría otra dirección base, pero gracias a la RVA (Relative Virtual 
Address) resulta posible cargar el resto del fichero binario sin tener que 
modificar nada más, ya que el resto de direcciones son o/Jsets respecto a 
esta dirección de base de la imagen. 


Otros elementos importantes de esta estructura son: 


» Sectionaligment, que determina el alineamiento de las secciones 
en memoria. Normalmente se define con el valor 0x1000, lo que 
indica que cada sección debe comenzar en una dirección de memoria 
múltiplo де 0х1000. Рог lo tanto, si la primera sección comenzara en 
la dirección 0x00407000, por ejemplo, aunque su tamaño fuera un 
solo byte, la segunda sección empezaría en la dirección 0x00408000. 


e Fileligment, que tiene una interpretación bastante parecida a la 
anterior, solo que se reficre al alineamiento físico de las secciones 
individuales directamente en el fichero en lugar de en memoria. Por 
defecto viene con un valor de 0x200. Esta alineación es especialmente 
importante para los virus para conseguir que cl tamaño del binario 
infectado no resulte mayor que el original, haciendo uso de los 
espacios sin ocupar por el alineamiento. 


» MajorSubsystemsVersion y MinorSubsystemVersion, determinan la 
version del subsistema Win32. 


+ SizeOflmage, que contiene el tamaño total de la imagen del fichero 
tras haberse cargado en memoria, se define como la suma de todas las 
cabeceras y secciones, alineamiento incluido. 





izeO/Headers representa la suma de todas las cabeceras, incluyendo 
la sección DOS, y tabla de secciones. Constituye, por tanto, la 
ubicación de la primera sección en el fichero. 


© Subsystem indica el subsistema NT al que va destinado el fichero. La 
mayoría de los programas Win32 definen el valor Windows GUI o 
Windows CUI (Graphic/Console User Interface) 
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+ DataDirectory, clemento de la estructura IMAGE DATA_ 
DIRECTORY con RVAs de estructuras importantes del fichero PE, 
por ejemplo, las tablas de importación o exportación. 


Y Tabla de secciones 
Seguidamente a la estructura IMAGE OPTIONAL HEADER, se 
encuentra la tabla de secciones que está representada en el fichero PE 
por la estructura IMAGE SECTION HEADER. El número de items 
en este elemento y. por tanto, también el número de estas estructuras 
se guarda en el clemento NumberO/Sections de la estructura IMAGE _ 
FILE_ HEADER. 


La definición de la estructura IMAGE_SECTION_HEADER es 





typedef struct IMACE SECTION HEADER { 
ZEOF SHORT MAME]; 






-aladdress 
DWORD Virtualsize; 

E Misc; 

DWORD Virtualaddress; 
WORD 
WORD 
тояр 
WORD 
WORD 
мао 
MORD 

} IMASE SECTION 


Donde: 
#define IMAGE SIZEOF_SHORT_NAME в 


Por lo que el tamaño de la estructura es de: 





§8+4+4+4+4+4+4 





4= 40 = 0x28 


Si extraemos el número de secciones de la cabecera PE concretamente en 
NumberOfSections dentro de IMAGE_FILE_HEADER, obtenemos Ox0€: 





Por lo que ya tenemos los datos para volcar las cabeceras de las diferentes 
secciones. Partiendo del offset justo tras IMAGE_OPTIONAL_HEADER 
localizado en 0x98+0xc0 = 0x178, podemos extraer los bytes para 


interpretar las cabeceras de las secciones: 





SRAMA 
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Cada sección es verde y a la derecha, se puede ver el 
IMAGE ЅЕСТІОМ НЕАРЕК, que 


tiene 8 bytes de longitud y debe terminar con un carácter nulo. Respecto 


elemento Name de la estructu 





al resto de elementos, se explican brevemente: 


© Misc, se utiliza con VirtualSize y contine el tamaño de la sección en 





niento, según el valor SectionAlignment. 





© VirtualAddress, determina el valor RVA de la sección. 


© SizeOfRawData determina el tamaño real de la sección en el fichero, 


endo el ali 





inclu 





ineamiento FileAligment. 
* PointerToRawData es un puntero al principio de la sección 
correspondiente en el fichero. 


e Characteristics describe las características de los datos de la sección, 


por ejemplo, de solo lectura, lectura y escritura, código ejecutable, etc. 


Con esto ya tendríamos todas las cabeceras de las secciones perfectamente 
identificada: 
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Se pueden ver estas secciones con la opción Memory (At+M) del debugger 


8 immunity Debuscer - aere - [Memory map 
mmli Optone Window Hep i 


Temtwh 





Si se hace doble clic sobre la sección PE header, se observa la estructura 
completa 
A immunity Debugger - 3 a [Dump-= 0010000) JODIE] 
[D] Fie View Debug Рыд к 

E AX FI FF 
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[Contenido acortado por motivos de espacio] 
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F Tabla de importaciones 
La tabla de funciones importadas o, más brevemente, importaciones, y 
especialmente las funciones de importación en sí, constituyen una de las 
piedras angulares de la arquitectura de la plataforma Win32. Una función 
importada consiste en una función invocada por el fichero PE, sin que 
el propio fichero la contenga. La tabla de importaciones del fichero 
contendrá toda la información necesaria para emplear las funciones 
importadas (nombre de la función, librería DLL, etc.) pero no la propia 
función, es decir, no el código objeto de la misma. 


Para que un fichero PE importe una función, otro fichero PE debe 
exportarla. Normalmente las funciones se suelen exportar mediante 
librerias DLL, ciertamente muy extendidas. 

El último campo de la estructura IMAGE_OPTIONAL_HEADER, 
contenida dentro de IMAGE_NT_HEADERS, incluye un campo de 16 
estructuras IMAGE_DATA_DIRECTORY denominado DataDirectory. 
Cada una de estas estructuras contiene información sobre el tamaño y 
RVA de algunas posiciones importantes del fichero. La definición de 
estructura IMAGE_DATA_DIRECTORY se muestra a continuación: 


typedef struct IMAGE DATA DIRECTORY Y 
DWORD VirtualAddress; 


DWORD Size; 
] IMAGE DATA DIRECTORY, *PIMAGE DATA DIRECTORY; 


VirtualAddress es la RVA de la estructura correspondiente, y Size su 
tamaño. No confundir VirtualAddress con Relative Virtual Address 
(RVA). Ya que a la primera debe sumársele el ImageBase. 

La siguiente tabla muestra los items más importantes del campo 
DataDirectory de estructuras IMAGE_DATA_DIRECTORY específicas 
y la información sobre los datos que contenga: 


LU09'SYDOGÁS' MA иә оредиооџа ола 
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Estas estructuras, se pueden ver claramente con los detalles del debugger 
donde aparecen seleccionadas en azul 





Immunity Debugger -aese - [Dump - a 00400000.00400FFF] 
1 не мем Оњо Plegins- inmi Options Window Нар Jobs 
i Jj lemtwhcPkb 





Se puede extraer esta información haciendo un volcado de bytes del 
fichero, para ello debemos saber la longitud del array DataDirectory 





#define INA 


Libro encontrado en: 
eybooks .com 
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Por lo que 16*8 = 128 = 0x80 Y sabemos que este array comienza en 
0x98+0x60 respecto al inicio del fichero, y de ahí podemos extraer la 
información así 





Como casí todo son ceros, la salida del comando ha sido recortada. 
5000 
n del debugger, coinciden con el 





Como se puede observar, los campos de “Import Table Addres: 
e “Import Table size 
volcado de bytes. 


218" de la imag 





er muestra todos los valores en 





Téngase en cuenta que el debug 
hexadecimal, aunque no lo indique con el prefijo “Ох”. 


mda estructura, contiene información sobre la tabla de 





importaciones. El valor de VirtualAddress en esta estructura será la RVA de 
la tabla de importaciones. Dicha tabla se define con la estructura siguiente: 


typedef struct IMAGE IMPOR 
union Y 





DESCRIPTOR 4 


озуп татты, /* RVA to o ч „ 
EIN 
DWD Tened: 














WORD Forwarderchain jes 
СИРО Nane, 
Онер, 

J ioe Heo 








Si nos di 
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ATT 
М н> view Debug Plagin Inmiib_ Options Widow Heip і 


o% MEXE ПЫ ИУ 








Una sección denominada .ídata que contiene imports. La tabla de 
importaciones finaliza con una estructura llena de caracteres nulos. 


Cada estructura IMAGE_IMPORT_DESCRIPTOR contiene información 
sobre la librería desde la que se importarán las funciones, de manera que 





si el fichero importa diez librerías, la tabla de importaciones IMAGE 
IMPORT_DESCRIPTOR contendrá diez estructuras más una estructura 


final rellena con caracteres nulos. 





El primer clemento de la estructura IMAGE_DESCRIPTOR será 
sustituido por OriginalFirstThunk. Esta variable contiene la RVA de 
IMAGE_THUNK_DATA que a su vez apunta a las estructuras IMAG 
IMPORT_BY_NAME (una por cada librería) y se define así: 








typedef struct IMAGE 
WORD Hint; 
ВҮТЕ Маве[1]; 

] IMAGE IMPORT BY_NAME, 





MAME 4 





РОВТ_ВҮ НАМЕ; 





Name contiene el nombre de la función en formato ASCII de tamaño 
Mexible. Cuando las funciones importadas carecen de estructuras 
IMAGE_IMPORT_BY_NAME, sc les denominan funciones ordinales y 


no se les importa según su nombre, sino su posición. 
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A modo de ejemplo se ve una parte de la tabla de importaciones: 





podemos ver tanto las direcciones reales de 





Si usamos el debug 
la tabla de importaciones, así como el nombre de las funciones, tras 


haberlas detectado el cargador dinámico. Para ello, una vez cn la ventana 
de código (Alt=C) se pincha en la ventana Dump; luego se pulsa Ctrl+G 


y se introduce 405000: 





09 SAOOÁ9" MA :иә оредисдиә олуг 
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Una vez cargado, se pincha con el botón derecho sobre las direcciones 





en la izquierda y se pincha con el botón derecho y se selecciona “Lo 





Address with ASCII dump’ 
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De esta forma se ven las funciones importadas, así como las librerias 
que lo contienen. Esto es posible porque esta vista, cuando detecta una 
dirección de memoria, accede a la etiqueta y la muestra. 


La siguiente imagen extraída de la documentación oficial muestra un 
diagrama de cómo se organiza esta estructura: 





F Tabla de exportaciones 


Por último, en la tabla de exportaciones, normalmente utilizada por las 
DLL, se utiliza la estructura IMAGE_EXPORT_DATA_DIRECTORY 
que se define asi: 


/* Bpart nodule directory "у 


typedef struct _INAGE EXPORT DIRECTORY { 
Charactersstzcs 








IFORT DIRECTORY , *P IMAGE_ EXPORT DIRECTORY; 
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wWww.eybooks.com 


Libro encontrado en: 


Y se accede e interpreta del mismo modo que las importaciones. En este 
caso, como no hay ninguna librería, dicha tabla está vacía. No obstante 
podemos ver el diagrama extraído de la documentación oficial 









5.3.2 Cargador dinámico 

El cargador dinámico de Windows es el encargado de gestionar las tablas 
de exportación e importación de los procesos cargados en memoria, además del 
propio proceso en sí. Para entenderlo un poco mejor, vamos a describir los pasos 
relacionados con la carga de un proceso en memoria previamente a su ejecución: 


1. En primer lugar se leen las cabeceras DOS, PE y de secciones. 


2. Se examina la dirección indicada en /mageBase del fichero binario para 
comprobar que esté disponible, si no es así, se reserva otra dirección 


disponible. 
3. Se utiliza la información de las cabeceras de las secciones para crear el 
mapa de memoria y colocar la información del fichero en las zonas de 


memoria reservadas. 
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4. Si el fichero no ha sido emplazado еп la dirección de memoria base 
indicada en el binario por /mageBase, realiza las modificaciones 
necesarias en el resto de direcciones de memoria de manera que queden 
reubicadas correctamente. 


5. Se navega a través de las secciones de librerías importadas, de manera 
recursiva, para cargar las secciones que no hayan sido ya cargadas hasta 
que todas las secciones requeridas haya sido cargadas en la imagen del 
proceso, 


Se resuelven todos los simbolos de importación en la sección de importación. 


Se reserva el espacio de memoria para las estructuras de memoria Stack y 
Heap segùn los datos indicados en la cabecera PE. 


Se crea el hilo inicial y se inicia el proceso. 


La parte más importante y de mayor interés para la ingeniería inversa es 
la carga de las librerías y la resolución dinámica de sus direcciones de memoria. 
El proceso no es trivial y conlleva la ejecución de funciones del sistema operativo 
que residen en ntdll dll y son invocadas mediante otras funciones que encapsulan su 
ejecución y conforman la denominada API (Application Programming Interface). De 
sta forma es posible reutilizar código de usuario en diferentes versiones del sistema 
operativo aunque se modifiquen las implementaciones internas de las funciones de 
nidll.ll. Estas funciones internas no están documentadas por Microsoft. Alguna de 
estas funciones encapsuladas son las conocidas, como por ejemplo GetProcAddress 
de la librería kernel32.dIl son simplemente una capa de abstracción (wrapper) de 
LdrGetProcAddress de la libreria пий 


Para una visión un poco más práctica de este proceso, vamos a utilizar 
Windbg cl depurador de código de Microsoft 


Si abrimos el binario aere, y establecemos un punto de interrupción 
(BreakPoint) justo en el EntryPoint (indicado en la cabecera PE del binario) podemos 
ver la invocación a funciones desde ndll.dl!: 
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Como se puede 
RilUserThreadStart, que es justo cl último paso del са 





servar en la pila de llamadas, la primera llamad: 
dor dinámico. Si queremos 
ver las invocaciones justo antes de esta función, podemos seguir paso a paso el 
código desde su carga del binario, donde 





es ntdll! 








pila de llamadas queda así 


E Cats Caer 


77 
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5.4 CUESTIONES RESUELTAS 


5.4.1 Enunciados 


1. ¿Qu 


de memoria”. 


а. МАСЕ NT_HEADERS 
b. EL IDENT 
ElI32_Ehdr 
_IMAGE OPTIONAL HEADER 
Elf32_Phdr 





estructura es la más adecuada para interpretar el siguiente volcado 


¿Qué valor tiene la variable EntryPoint partiendo de los datos 
proporcionados? 


0x40001000 
0x00401000 
0x00400400 
0x00801000 
0x00802000 





ificada?: 





¿En qué dirección finaliza la sección i 
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а. 0х00000027 
ь. 0х00000040 
с. 0х0000002ғ 
d. 0x0000003F 
e. 0x0000005f 


4. ¿En qué estructura de datos estarían contenidos los siguiente bytes?: 





a. IMAGE MZ HEADER 
b. _IMAGE_OPTIONAL_HEADER 
с. [IMAGE NT_HEADER 

d. IMAGE PE HEADER 

€. _IMAGE_DOS HEADER 


La siguiente estructura de datos, ¿en qué dirección daría comienzo”. 





a. 0x7E 
b. 0x80 
с. 0х81 
d. 0x30 
e. 0x2F 


6. ¿En qué dirección comenzará la ejecución tras cargarse el binario en 





a. 0x00401130 
0x00003011 
0x40001130 
0x00403011 
e. 0x00001130 
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7. La portabilidad entre distintas arquitecturas de hardware siempre y 
cuando mantengan el mismo sistema operativo, ¿a qué es debido?: 
a. API 
b. EAPI 
e. ABEL 
d. ABI 


8. ¿Qué define la interfaz entre el código fuente y las bibliotecas?: 


a. API 
b. EAPI 
с. АВЕ! 
d. ABI 


9. ¿Qué tipo de objeto no puede ser un fichero binario ELF?: 


a. Objeto reubicable 
b. Libreria portable 
e. Ejecutable dinámico 
d. Objeto compartido 

10,¿Qué tipo de ficheros binarios no están derivados del formato COFF?: 


a PE 
b. ELF 
e. DEX 


5.4.2 Soluciones 


10.e 
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5.5 EJERCICIOS PROPUESTOS 





1. Implementar en el lenguaje que se desee, un programa para detectar el tipo 
de fichero binario. Si fuera ELF o PE, extraer las cabeceras principales: 


2. Implementar en el lenguaje que se desee, un programa para detectar qué 
funciones externas necesita el binario para ser ejecutado: 








ANÁLISIS ESTÁTICO: 
DESENSAMBLADORES Y 
RECONSTRUCTORES DE CÓDIGO 


Introducción 


En esta unidad didáctica se explicará el concepto de análisis estático aplicado 
a la ingeniería inversa. También el concepto de desensamblador y reconstructor de 
código, así como una enumeración de herramientas capaces de automatizar estas 
tareas. 


Objetivos 


Cuando el alumno finalice la unidad didáctica será capaz de implementar un 
desensamblador basándose en las especificaciones del fabricante, así como utilizar 
diversas herramientas para el desensamblado y reconstrucción automático de código, 
pudiendo interactuar con estos procesos para llevar a cabo diferentes acciones. 


6.1 CONCEPTOS INICIALES 








Al llevar a cabo labores de ingenii 
de enfoques: 


ia inversa, se pueden realizar varios tipos 





F Análisis estático: que es el tipo de análisis que vamos a cubrir en esta 
unidad, y que trata de analizar el binario sin llevar a cabo la ejecución del 
mismo. Esto es posible gracias a los desensambladores (disassemblers) 
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que convierte el código binario a código ensamblador. Es decir, 
interpretan los opcodes y muestran su interpretación en mnemónicos 
y operandos. Este tipo de análisis es necesario cuando no es posible 
ejecutar el código, ya sea porque es algún tipo de malware, porque no se 
dispone de la arquitectura que lo pueda ejecutar, porque el sofware tenga 
comportamientos diferentes según el entorno donde se ejecute para evitar 
su depuración, o por cualquier otro motivo. 


Análisis dinámico: este tipo de análisis lo veremos cn la siguiente unidad, 
y consta de llevar a cabo la ejecución del código para poder determinar 
qué es lo que hace y cómo lo hace. Para ello se utilizan depuradores 
de código, que permiten ejecutar el código pudiendo parar сп cualquier 
momento y analizar el estado de los registros y la memoria, pudiendo 
así analizar de qué manera manipula los datos. En este tipo de análisis 
se encuadra el denominado análisis de comportamiento, que trata de 
observar el comportamiento en cuanto a qué recursos utiliza, qué tráfico 
de red realiza, qué ficheros y de dónde los lee y/o escribe, qué funciones 
del sistema ejecuta, si es o no automodificable, si se comporta de una 
manera u otra dependiendo de sí se ejecuta en un entorno u otro, ete. 


A menudo se llevan a cabo análisis mixtos. Es normal llevar a cabo un 
análisis dinámico tras un análisis estático, pero no siempre que se hace un análisis 
dinámico se lleva a cabo uno estático. Esto es debido a que los análisis dinámicos 
suelen estar automatizados para poder analizar miles de muestras en poco tiempo, 
como es el caso del análisis de malware. Sin embargo, para otros entornos donde se 
pueden tardar días, semanas o incluso meses en tareas de ingenieria inversa con un 
solo software, lo normal es realizar análisis estático, luego dinámico e ir intercalando 
y mezclando los análisis, para poder extraer información aplicable a cada uno de 
los análisis. Este es el caso por ejemplo de la construcción de herramientas libres a 
partir de software o protocolos privados, el análisis de vulnerabilidades o análisis de 
malware entre otros. 





6.2 DESENSAMBLADORES 








Los desensambladores propiamente dichos son las herramientas capaces 
de traducir el código binario en instrucciones de lenguaje ensamblador, es decir, 
interpretar los opcodes y traducir a memónicos y operandos. Esta tarca está 
ampliamente extendida y es relativamente sencilla de implementar. 
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6.2.1 Conceptos básicos 


Para poder desensamblar un código binario, han de tenerse en cuenta diversas 
cuestiones: 


F Formato de fichero binario: esto es lo primero a tener en cuenta, 
ya que cl código ejecutable no suele comenzar al inicio de un fichero, 
sino que está contenido en un fichero con un formato binario concreto 
que especifica la arquitectura para la que debe ejecutar, así como 
información de dependencias y demás opciones que preparan cl entomo 
de ejecución del binario. 


F Especificación de la arquitectura objetivo: una vez conocida la 
arquitectura para la cual se ha creado el código binario ejecutable, es 
imprescindible conocer los detalles de dicha arquitectura, para poder 
interpretar los opcodes correspondientes, además del tipo de alineación 
y detalles especificos de la arquitectura. Este tipo de información en 
teoria la proporciona el fabricante, aunque en la práctica, en demasiadas 
ocasiones, es información obtenida mediante ingeniería inversa hacia los 
propios microprocesadores, ya que aunque sí se publican ciertos detalles, 
no suclen liberar toda la información de manera libre, sino que se les 
proporciona a las empresas que desarrollan compiladores de manera 
preferente previo pago. A continuación se muestra la especificación 
oficial del fabricante de procesadores Intel: 


E E EE SRR EERE 
yy 
ЕСЕ наар 
ае 
ЗЕЕ 
аа 








1ls/64-ia-32- 





Con esta información ya se puede desensamblar el código binario que se 
necesite. Esta labor se lleva a cabo conociendo el tamaño del opcode y luego en 
función del que sea se analizan los operandos o el siguiente opcode. 





Para una mejor comprensión del proceso vamos a poner el siguiente ejemplo. 
Partimos de una serie de bytes: 
5531 0289 E5 83 
53 80 58 FF OF Bê 
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Sin ningún tipo de información, esto podría ser cualquier cosa, un bloque 
de una imagen JPEG, una parte de un fichero de audio, ete Pero si sabemos que es 
código ensamblador para un procesador 1386 podemos consultar los opcodes de esta 
arquitectura y podremos traducir estos valores en hexadecimal a código ensamblador. 
Para ello vamos a consultar la documentación proporcionada anteriormente, En ella 
se puede ver en Vol. 28 4-271 (segundo PDF, página 273) la siguiente tabla: 


















ш $ ER Mode Ley 
Mores 
Sant o Cot sartor bao 
Instruction Operané Encoding 
ит раат orano z ema аана 
енти м м м 
o caera m m м 
No vemos el SS, pero sí vemos un “SO + rd". Esto significa que el 50 indica 
PUSH 132 y 132 será el registro cuyo valor coincida en la siguiente tabla (primer 
PDF, página 36): 
minar гй 
кейн eee їп 





Es decir, que sí tenemos ша 50 + гй = 55 entonces rd = 5 (EBP), por lo que 
la instrucción es: 
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PUSH EBP 


Esto se entiende mejor si lo analizamos en formato de bits, donde los bits más 
significativos son los que indican el tipo de operación, y los de menos peso el registro: 


msa [9 
0101 = PUSE eE 
Z om 
AAA 





Luego pasaríamos a analizar cl 31 ( 0011 0001 ), si observamos en la 
siguiente tabla Vol. 2C 8-17 (tercer PDF, página 90): 
































EAT 
ста 

талгат 

merar torest 

rete ta пету 1001 oom: mod reg cin 

imeat to regter C 

үттөдат ъ А Ах FERE 01 0O a 

tender memo [T00 one med 110 этейик нт 





Como podemos ver, se trata de la instrucción XOR con dos registros. Para ello 
vamos a tener que leer otro byte mås que nos indica qué registros son, y el siguiente es 
el D2. Si vemos de nuevo la tabla (primer PDF, página 36) pero de manera completa: 
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EL авзезава аата ч: 


apa EERE 
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Vemos cómo register 1 (fila) 
que los bytes 31 d2 se interpretan como: 


EDX y register? (columna) = EDX por lo 


XOR EDX, EDX 


Así podríamos continuar hasta cl final de manera sistemática y se podria 
desensamblar todos los bytes proporcionados. 


Nótese que si esos bytes fueran interpretados con unos bytes de desfase, es 
decir, en lugar de leer 55 31 D2 ... se leyera directamente D2 ..., el opcode de D2 
ROR y esto cambiaría por completo el contexto de la ejecución, y D2 pasaria de 
un operando a un mnemónico. Esto es importante tenerlo en cuenta sobre todo a la 
hora de descifrar código automodificable o cifrado. Con tan solo desplazar un byte el 
origen, el resultado de las operaciones es totalmente diferente, 








6.2.2 Herramientas disponibles 


Vamos a mostrar una pequeña lista de herramientas disponibles para realizar 
el desensamblado de manera automática y efectiva. El orden de presentación es 
totalmente arbitrario, no implica ningún orden de importancia ni preferencia. 





F ODA - The Online Disassembler 


Es un desensamblador de uso libre basado en web y que soporta una 
gran variedad de arquitecturas. Se puede utilizar en vivo y ver el código 
desensamblado en tiempo real, ya sea copiando una serie de bytes o 
subiendo un fichero. El proyecto aún está en fase beta, pero se espera que 
mejore con el tiempo. La URL del sitio es 


Ҹ hups:/hwwwconlinedisassembler.com/odaweb 


Explicamos en primer lugar esta herramienta, para continuar con la 
explicación anterior con el ejemplo de los bytes. Si vamos a la web € 
introducimos los bytes anteriores: 
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Como se observa en la imagen, las dos instrucciones desensambladas se 
han desensamblado correctamente. 


Si se pincha en el icono rojo (Platform: i386) se pueden establecer 
opciones de desensamblado: 


этш 
ES 
= 





De entre las que se pueden seleccionar multitud de arquitecturas. Si соп 
los mismos bytes, establecemos otra arquitectura por ejemplo armvS: 















Vemos como además de no ser las mismas instrucciones, ni siquiera 
parecen hacer lo mismo: comienza sumando un valor al registro y luego 
leyendo otro registro que no tienen nada que ver lo que hacía antes. 
Además, si se observan los hytes se ve como se leen en orden inverso: 31 
55 y 89 D2. Esto es porque este procesador lec las instrucciones en orden 
inverso debido al Endianness. 
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¥ Objdump 
Esta herramienta que ya hemos utilizado en unidades anteriores, es 


básica en Unix y permite entre otras cosas mostrar el desensamblado de 





un binario. Para ello debemos utilizar la opción -S y nos permite escoger 


entre varias arquitecturas así como sintaxis y direccionamiento: 





Si compilamos el ejemplo de la Mustración 22 y procedemos a su 


desensamblado, veremos esto: 
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Si queremos ver ese mismo desensamblado con sintaxis Intel en lugar de 
AT&T 





Como se puede observar los bytes son los mismos, pero la sintaxis del 
lenguaje ensamblador cambia. 





F ndisasm 
Este es el desensamblador por defecto de los sistemas Unix/Linux. El 
funcionamiento es muy básico. De las pocas cosas que permite, una es 


comenzar a desensamblar en un offset concreto o saltar bytes. Esto es 











especialmente útil para analizar рогсіо 





es de código automodificables 


o extraído de sitios no comunes, como puede ser un shellcode. La 
sencillez de esta herramienta la hace ideal para scr utilizada por debajo 
en herramientas con otros propósitos. 


F Capstone 
Esta herramienta merece una mención especial por varios motivos: 
© Es open-source 
© Soporta multitud de arquitecturas. 

+ Es muy robusto y estable. 


e Se están llevando a cabo tareas de desarrollo muy exigentes que 
permiten tener versiones estables en muy poco tiempo, En menos de 
dos años ya van por una versión 3 estable recién liberada. 
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En su web se pueden leer más detalles sobre sus ventajas frente a otros: 


Highlight features 





Para conocer más detalles del proyecto se puede visitar su página web 
/ hitp:/hvww:capstone-en 





F IDA Pro 


Esta herramienta es sin duda la herra efecto de cualquiera que 








lleve a cabo labores de ingeniería inversa. Es un framework interactivo de 





desensamblado que permite al usuario intervenir en las diferentes fases 





del análisis y desensamblado, así como de los cargadores iniciales que 
permiten analizar binarios como PE, ELF, PlayStation, Gameboy, Java, 
Dalvik, ete., y por supuesto el depurador de código. 


Además de poder interactuar con las distintas fases de la ca 





desensamblado, permite una visualización en forma de gráficos de 





ejecución, basado en bloques básicos, que permite una mejor visualización 
del Aujo de código que con código ensamblador mostrado de forma lineal. 


Véase la diferencia 


Código ensamblador de forma lineal. 
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Código ensamblador mostrado de forma gráfica. 
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La diferencia es apreciable a simple vista. Esta forma de representación es 
más intuitiva y es aún de mayor ayuda cuando se utilizan los colores para 
marcar los bloques básicos ejecutados en una instancia, o simplemente 
para marcar los bloques básicos con algún tipo de interés para el usuario. 
ente se ve la función anterior con los bloques básicos 
jecutados por el depurador de código en una 





En la imagen siga 
coloreados al haber sido 





ejecución concreta 
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De esta forma, se focaliza la atención en los bloques básicos importantes 
para al análisis y evitan que se desvie la atención con información 
superflua. 


Además de las vistas, también es capaz de interpretar datos importantes 
como la pila: 





En la parte de la izquierda, se ven los offset en relación al marco de 
pila, con el signo — y + que indica si está por encima o debajo de EBP. 
A esta información se accede simplemente pinchando dos veces sobre la 
variable local o argumento de función deseada. El valor del EBP anterior 
se nombra con la variable “s" y el valor de la dirección a la que volverá 
cuando se finalice esta función, es decir el valor de retomo de la función, 
se define como ‘r’. Este es el valor a sobre escribir cuando se pretende 
explotar un fallo del tipo Stack Overfiow 


La herramienta al abrir un nuevo fichero binario, va realizando pasadas 
por el código para ir interpretando la información que va detectando. 
Esto se ve en la barra superior, y una flecha que la va recorriendo. Una 
vez ya no puede obtener más información, se indica poniendo el valor de 
estado “completado” (un icono en forma de luz verde indica este estado), 
que es cuando se debe comenzar a trabajar con la herramienta. 








Otra de las características notables en este desensamblador, es la capacidad 
para detectar rel 
función, variable o dirección de memoria, y poder obtener un listado de 
además del tipo 
de referencia, si es de lectura o escritura. En la función anterior, si nos 
vamos a la función printf y pulsamos Ctrl+X, podemos ver esto: 





cias cruzadas. Esto permite posicionarse sobre una 





diferentes localizaciones donde se hace ref 
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« 


Diresti yy Adrem Ta 





Una lista, en este caso de una sola linea, de localizaciones donde se ha 


hecho uso de printf 





Sin duda, el mayor potencial de IDA es la capacidad para interactuar con 
él de manera automatizada, ya sca mediante plugins escritos en C++, o 
bien mediante scripts en lenguaje IDC, un lenguaje de scripting diseñado 
por IDA para su automatización, o en las últimas versiones, Python, a 
través del plugin IDAPython, y que desde hace varias versiones forma ya 
parte de la herramienta. Se pueden escribir ficheros con extenso código 
para funciones especi 
linea de comandos que hay en la zona inferior de 
puede ver en la siguiente imagen: 








icas, o escribir directamente instrucciones en la 
herramienta, como se 
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Se pueden ejecutar, no solo comandos de una linea, sino multilinea: 


pa 1» 
еза a 
БЕ EJ 









aput werdor 








En este ejemplo de varias líncas se listan las funciones del segmento 
actual y desde donde son invocadas. Para ello solo hay que ir escribiendo 
y pulsar dos veces la tecla Intro para que se interpret 
No obstante la manera mås común para ello, es mediante un script en 
-py para posteriormente abrirlo desde el menù o pulsando AIt+F7. Los 
comandos disponibles están documentados en la documentación oficial 
de IDAPython en su web, anteriormente citada. También es posible 
interactuar con el depurador de código mediante IDC y Python. 


el comando. 











No se pretende hacer un manual sobre esta herramienta, simplemente 


destacar sus funcionalidades como desensamblador y por qué es el más 








utilizado, 
IDA Pro se puede comprar en el siguiente enlace: 
S https://www.hex-rays.com/products/ida/order. shtml 


Existen versiones de prucba de IDA en su versión más actual con 
diferentes limitaciones que la hacen inviable para un uso práctico: 


4 hitps://www.hex-rays.com/products/ida/support/download_demo.shtml 
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Y por otro lado existe una versión freeware, totalmente operativa, pero 
con bastantes limitaciones debido а la antigúedad de la versión 5.0 que 
es la que ofrecen: 


Y huips://nrwwhex-rays.com/products/ida/support/download_ freeware. 
shtml 


Hay muchos más desensambladores, por ejemplo, todos los depuradores 
de código contienen un desensamblador por motivos obvios. Sin embargo en esta 
unidad solo se pretende familiarizar al lector con este tipo de sofiware y cuåles son 
sus caracteristicas más destacables. 


6.3 RECONSTRUCTORES DE CÓDIGO 





En los capítulos anteriores, se ha visto cómo es posible llevar a cabo las 
tareas de reconstrucción de código para conseguir convertir el código objeto a código 
fuente, Estas tarcas son más o menos sencillas y/o exactas, pero en cualquier caso 
es convertible a código fuente. El problema es la pérdida de información contenida 
en el código fuente original, como el nombre de variables y agrupaciones concretas 
de variables como estructuras, objetos u otras casuísticas, como el hecho de que 
el optimizador de código climine o modifique determinadas instrucciones que 
originalmente fueran de otra manera cn el código fuente. 


Todas estas tareas de reconstrucción han sido identificadas e implementadas 
siendo posteriormente automatizadas, de esta forma, una labor manual que puede 
llevar días o semanas dependiendo de la cantidad de código binario, puede ser llevado 
a cabo de manera automática por determinados sofíware. Además, la automatiza 
evita errores humanos en cl momento de la reconstrucción manual. 





Este tipo de herramientas son indispensables en tareas de ingeniería inversa, 
y ayudan en gran medida a la rápida comprensión del funcionamiento del sofóware 
analizado. En la mayoría de los casos, esto no evita la intervención humana, ya que 
el usuario de este tipo de herramientas, será capaz de agregar más contexto a la 
reconstrucción gracias a su conocimiento o información no extrapolable desde el 
binario. Como por ejemplo el conocimiento sobre el funcionamiento de funciones 
que la herramienta de reconstrucción de código no conoce, Esto es un caso común, 
ya que una persona es capaz de acceder rápidamente a la documentación de la API 
de una librería, o la búsqueda de información sobre una función concreta, mientras 
que una herramienta de reconstrucción de código, debe esperar a que actualicen sus 
firmas para agregar estos datos a la reconstrucción. 
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6.3.1 Herramientas disponibles 


No hay una gran variedad de reconstructores de código disponibles, y muchos 
de los que hay, creados por universidades, o particulares, o no siguen mantenidos 
o su desarrollo es lento e incompleto para determinadas plataformas. Sin duda el 
desensamblador por excelencia es Hex-Rays: 


Y hups:/Awwn:hex-rays.com/products/decompiler/index-shtml 


Que viene en forma de plugin para cl framework de desensamblado IDA Pro: 
Y hups:/hwww:hex-rays.com/products/ida/index-shtml 
Que comentaremos como apartado especial de la unidad con más detalle. Sin 
embargo hay otros reconstructores de código que vamos a comentar someramente: 


r vec 





Este es uno de los reconstructores de código más antiguos que existe. Sus 
inicios son de hace más de 20 años, cuando su autora Cristina Cifuentes 
preparaba su doctorado en la Universidad de Queensland en Australia 
durante los años 1991-1994. Su web original ya no existe, pero se puede 
consultar en el siguiente mirror: 


Ҹ https://web.archive.org/web/20131209235003/http:/itee.uq.edu.au/ 
—cristina/dcc.html 


En 2015, parece que el proyecto vuelve a estar en activo, donde se están 
llevando a cabo correcciones y cambios, por ejemplo relacionados con un 
front-end basado en QS: 


Y hups://github.com/nemerle/dec 
F Boomerang 


La autora de DCC, Cristina Cifuentes participó activamente en el 
compilador Boomerang, como un reconstructor de código de varios 
lenguajes máquinas a código C. El proyecto aunque estable tiene poca 
actividad. 


La página web del proyecto es la siguiente: 


Y hups//github.com/nemerle/boomerang 
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F ROSE source-to-source Compiler 


En el año 2000, se publicó el siguiente paper: 


Y hup://rosecompiler.org/ROSE_ResearchPapers/2000-ROSECompile 
rSupportForObjectOrientedFramenorks-CPC pdf 


Y dio comienzo al proyecto ROSE. Un framework de compilación source- 
to-source de código abierto, basado en representaciones y lenguajes 
intermedios. De esta forma, es capaz de pasar de varios lenguajes fuentes 
o binarios a otros lenguajes fuentes o binarios, tal y como muestras la 
siguiente imagen: 














La página web del proyecto es la siguiente: 
S http:/rosecompiler.org/ 


F Retargetable Decompiler 


Este caso es especialmente interesante porque, si bien no es posible 
acceder a su código ya que es un servicio web, al estar patrocinado por 


ORAMA 
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empresas privadas(AVG entre ellas), parece que tienen mayor actividad y 
los resultados son de bastante calidad. La idea de esta herramienta online 





es ser capaz de reconstruir código de varias plataformas y convertirla 


en cûdi n las opciones de la 





o C o Python, tal y como se puede ver 





siguiente ima; 








Aunque el código no es accesible, es posible utilizar la herramienta de 
manera automatizada a través de su APL. Para ello hay que crearse una 
cuenta y utilizar el identi 
vía peticiones REST style. Se puede visitar la página oficial mediante el 





cador para poder interactuar con la herramienta 


siguiente enlace: 


Y huips://retdec.com 
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F MC-Sema + LLVM 


LLVM cs un framework de compilación muy potente y modular que 





sermedio y conocido como bytecode. 
лаје сп С рог ЦУМ. 


permite trabajar con los lenguaje i 
Estos bytecodes pueden ser traducidos a un le 











$ lle -march=c hellowo; o helloworld. 








Normalmente este códig jerado por el propio LLVM a 
partir del código en C, con la opción -emit-llvm. Pero como no tenemos cl 





en bytecode es 





código en C, que es lo que tratamos de obtener; podemos utilizar MC-Sema 
«pretable por LLVM: 





para convertir el código ensamblador a bytecode 








F Lo que nos crea un fichero bytecodes que lu 
C con LLVM tal y como hemos visto antes. 


F Este método es muy potente, ya que permite no solo reconstruir códi 





sino manipularlo, ya que LLVM permite la ejecución de bytevodes 
incluso se podría insertar código cn el binario, 


6.3.2 Hex-Rays Decompiler 


Ya que este es el reconstructor de código por excelencia, o al menos el más 
fiable, completo, de uso extendido y gran aceptación en el mundo de la ingeniería 
inversa, vamos a dedicar este apartado a conocerlo un poco más en detalle. 


Hex-Rays es un plugin para IDA Pro, que permite la reconstrucción de 
código de x86 32/64 bits y ARM, a pseudocódigo en C. Al iniciar la herramienta, 
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en la ventana de estado, nos aparece el mensaje de que ha sido cargado el plugin y 


después un texto que dice así 





Esto nos indica que si nos posicionamos sobre una función y pulsamos FS. 


veremos su reconstrucción; por ejemplo, con la función anterior veríamos esto: 


¡DA viera paradocaces 2 | [| бекйе»1 s€ | FD) Stee 





Y si se quiere reconstruir todo el código habría que pulsar Ctrl=FS, donde 
aparecería una ventana de dialogo preguntándonos por el nombre y la ruta del fichero 


donde guardar la reconstrucción total del binario. 
vamos a explicar 





Para poder ver el potencial de este reconstructor йе сб 
mejor un ejemplo. Para ello vamos a basarnos en un código de unidades anteriores, 


en concreto el de la Hustración 18: 
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Si lo abrimos con IDA vamos a ver esto: 
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Si nos posicionamos en la función main y pulsamos FS se verá el 


pseudocódigo obtenido: 





Si nos posicionamos justo encima de los valores numéricos y pulsamos H el 


valor se convierte a hexadecimal: 


El reconstructor no sabe qué codificación es más intuitiva para el usuario 
final, por lo que hay que establecer la codificación que se requiera. 


Ahora vamos a pinchar dos veces en sub_8000000 y accedemos al código. 


Pulsamos de nuevo en FS y vemos lo siguiente 


Libro encontrado en: Wwww.eybooks.com 


Aquí también podemos establecer la codificación hexadecimal en los valores 
posicionándonos sobre el valor y pulsando H. Ahora vamos a centrarnos en la variable 
al esta es accedida de manera directa y con un desplazamiento. Como hemos visto 


en unidades anteriores, esto es debido a que en realidad hay una estructura. Vamos 
иа рага que detecte de forma automática dicha 





a utilizar la potencia de la herrami 
tructura, Para ello vamos a posicionarnos sobre al y pinchamos con el botón 


en Create new struct type y vemos la estructura propuesta: 
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tions Mindows 








Si le damos a OK vemos como ha aplicado esta estructura en el còdigo 


reconstruido: 


oro encontrado en: www.eybooks. com 


Con estos pequeños pasos hemos obtenido un código bastante acertado 


respecto al código original 
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Nótese que aunque en el código ensamblador si existen las variables ì y j, 
en reconstructor de código en la fase de optimización ha eliminado código muerto. 
Esas variables solo se inicializan, pero no se utilizan, por lo que se eliminan de la 
reconstrucción. 


Esto muestra el hecho de que, por bueno que sea el trabajo hecho por una 
herramienta de reconstrucción de código de manera automática, es necesaria la 
intervención del usuario para mejorar el código fuente obtenido. 


También es posible acceder al plugin Hex-Rays mediante código script en 
IDC o Python, tal y como se puede ver en la siguiente imagen: 





ii Savors = om133333337 
Tetun resolta 





O mediante plugins a través el SDK de Hex-Rays: 


Y hups:/pwww.hex-ra 
shtml 





;.com/products/decompiler/manual/sdk/examples. 





De esta forma, se pueden Ilevar a cabo tareas automatizadas bencficiándose 
de la reconstrucción de código llevada a cabo por Hex-Rays. Téngase en cuenta que 
se puede acceder no solo al código reconstruido, sino al AST (Abstract Syntax Tree) 
del código, lo que permite analizar de manera detallada el código reconstruido y 
permite agregar funcionalidades o heurísticas. En el blog oficial hay varios artículos 
al respecto de entre los que destaca: 


Y Inp:/hwww.hexblog.com/?p=107 





En el sitio web de IDA se pueden consultar varios recursos, entre los que hay 
tutoriales sobre tipos de datos, análisis gráfico y demás funcionalidades: 





Y hips://www:hex-rays.com/products/ida/support/tutorials/index.shtml 
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6.4 CUESTIONES RESUELTAS 





6.4.1 Enunciados 


1. Los siguientes bytes, ¿para qué tecnología están destinados?: 


55 31 D2 89 E5 8B 45 08 56 8B 75 0C 
53 8D 58 FF OF B6 OC 16 88 4C 1301 


83 C2 01 84 C9 75 F1 5B 5E 5D C3| 





i386 

amd64 

arm-Thumb2 

mipsel 

No es posible determinarlo. 


2. Silos siguientes bytes, fueran código x86-32 bits, ¿cuál sería la primera 
instrucción? 





55 31 D2 89 E5 8B 45 08 56 8B 75 0C 
53 8D 58 FF 0F B6 0C 16 88 4C 13 01 
83 C2 01 84 C9 75 F1 5B 5E 5D C3) 


PUSH ESP 
PUSH EDX 
RETN 

XOR EDX.EDX 
PUSH EBP 


3. ¿Qué hace un reconstructor de código?: 


a. Convertir hytes sin formato a código ensamblador. 
b. Convertir código ensamblador a código fuente. 
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e. Convertir código ensamblador que no funciona correctamente a 
código ejecutable sin errores, 

d. Convertir las llamadas indirectas producidas por las VTables, a 
llamadas directas a direcciones concretas. 





4. ¿Afecta la sintaxis a la manera de interpretar los hytes?: 


a Si 
b. No 
e. Depende 


5. ¿Qué sintaxis se ha utilizado ca la siguiente imagen?: 





а. МІМАРІ 
b. cdecl 

c. Intel 

d. stdeall 
e. AT&T 


6. ¿Es posible reconstruir un código completamente sin ayuda del usuario? 
No 

Solo si el usuario introduce las estructuras que el binario utiliza. 
Solo si el usuario proporciona los simbolos de depuración. 

Si 

No, aunque sí se pueden conocer el número de funciones. 
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7. Existe una amplia variedad de reconstructores de código tanto de manera 
comercial como de software libre- 


a. Verdadero 
b. Falso 


$. Una misma secuencia de bytes será interpretado de manera diferente 
según la herramienta de desensamblado que se haya utilizado: 


a. Verdadero 
b. Falso 


9. Un reconstructor de código se encarga de convertir un conjunto de bytes 
en código ensamblador definido por el fabricante de una arquitectura 
concreta: 


a. Verdadero 
b. Falso 


10.Un desensamblador de código se encarga de convertir el còdigo 
ensamblador en código fuente: 


a. Verdadero 
b. Falso 


6.4.2 Soluciones 
La 
е 
3.b 
аъ 
5.e 
6d 
7.b 
8.b 
9.b 
10.b 
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6.5 EJERCICIOS PROPUESTOS 





1. Implementar un programa que sea capaz de desensamblar el siguiente 
fragmento de código en x86-32: 





55 31 D2 89 E5 8B 45 08 56 8B 75 0C 
53 8D 58 FF 0F B6 0C 16 88 4C 13 01 
83 C2 01 84 C9 75 F1 5B 5E 5D C3| 


Ф мотд 
código manualmente. Después introduzca esa información en algún tipo de datos para 
convertir estos bytes en código ensamblador x86-32b1s correctamente. 





2. Realice la misma operación de antes pero para la arquitectura que desee, 
por ejemplo ARM. 








ANÁLISIS DINÁMICO: 
DEPURADORES DE CÓDIGO 


Introducción 





En esta unidad se estudia el análisis dinámico de binarios, donde se utilizan 
los depuradores de código y otras herramientas de análisis de comportamiento para 
¡conocer qué es lo que hace el binario y cómo lo hace desde un punto de vista dinámico, 
es decir, ejecutando el binario. Además sc enseñan los detalles de implementación de 
depuradores de código en Linux y Windows. 


Objetivos 


Cuando el alumno finalice la unidad será capaz de analizar un fichero binario 
y saber qué hace y cómo lo hace mediante técnicas de análisis dinámico. Además, 
será capaz de implementar un sencillo depurador de código, tanto en Linux como en 
Windows. 


7.1 ASPECTOS GENERALES 





En esta unidad vamos a ver cómo llevar a cabo análisis de binarios desde 
un punto de vista dinámico, llevando a cabo la ejecución del mismo y analizando 
tanto su comportamiento externo, es decir, qué librerías utiliza, con qué ficheros 
interactúa, qué tráfico de red genera, a qué recursos del sistema accede. Así como de 
manera interna, analizando la carga del binario en memoria, el proceso de arranque 
del mismo, los algoritmos que utiliza para llevar a cabo comprobaciones y/o 
acciones, viendo en definitiva cada una de las instrucciones ensamblador que ejecuta 
y analizando porqué y para qué lo realiza. 
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El análisis de comportamiento, se conoce como caja negra, ya que no se 
tiene conocimiento de su estructura intema. Tan solo se interactúa con el programa 
como si fuera algo cerrado al que le podemos enviar información, y este realiza 
acciones diversas con esa información y del que tan solo podemos analizar el 
resultado externo de esas acciones, como hemos dicho antes: generar tráfico de red, 
acceso a ficheros, recursos del sistema y demás. 


Por otro lado se conoce como саја blanca el tipo de análisis donde se accede 
al interior del programa, es decir, al propio código ensamblador del mismo, y se ejecuta 
dicho código pudiendo acceder a cada instrucción de manera controlada, pudiendo 
ejecutar cada una de las instrucciones paso a paso, pudiendo examinar tanto los 
registros del procesador como la memoria al completo del proceso en cada instrucción. 


El motivo principal de porqué se realiza un tipo de análisis u otro suele ser 
siempre el tiempo. El análisis de comportamiento se puede Ilevar a cabo de manera 
desatendida, pudiendo recopilar toda la información para su posterior estudio. Por 
regla general, el tipo de información que se busca es fácilmente detectable con este 
tipo de análisis. Por ejemplo, en el caso del malware, suelen ser sofiware que se 
despliegan en fases. Es decir, en primea instancia un software llega por correo, 
publicidad web, redes sociales o cualquier otro medio, y este software conecta con 
un sitio web controlado por el atacante donde descarga otro software, дие ез еп 
realidad el que lleva a cabo las acciones más complejas y peligrosas del malware. 
Esto se conoce como un dropper de 2 etapas. El software de la primera etapa no es 
interesante conocer su funcionamiento interno, y de hecho, si se tratara de hacerlo, 
habria que lidiar con técnicas antidepuración у antianálisis, lo que conlleva un gasto 
importante de tiempo. Lo que interesa es conocer la dirección IP o URL a la que se 
conecta para descargar e instalar el software de la segunda etapa. 


En escenarios fuera del mundo del malware, se puede querer realizar análisis 
de caja negra para comprobar que un software no accede donde no debe, que lleva a 
cabo las acciones que debe, sin invadir la necesidad de divulgar el contenido de los 
algoritmos que los realiza. 


Por otro lado, los análisis de caja blanca, se llevan a cabo cuando se quiere 
Obtener un conocimiento profundo sobre el software analizado. Ese conocimiento no 
es posible obtener tan solo con un análisis estático, sino que se necesita ejecutar el 
programa y ver cómo se comporta al proporcionarle determinada información. Este 
es el caso claro de los análisis de vulnerabilidades, donde se necesita saber no solo 
cómo se supone que trabaja el software, sino en unas circunstancias concretas, cómo. 
lo está haciendo. Y esto depende del escenario, es decir, arquitectura, opciones de 
configuración, opciones del compilador, etc. Este tipo de datos no son extrapolables 
simplemente con un análisis estático, y aportan resultados fiables sobre si algo pasa 
de una forma u otra. 
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A continuación vamos a explicar de forma más detallada los dos tipos de 
análisis, 


7.2 CAJA NEGRA: ANÁLISIS DE COMPORTAMIENTO 





El análisis de comportamiento, se lleva a cabo interceptando el envío y 
recepción de información entre el proceso a analizar y el sistema operativo, como puede 
ser el caso de la red, los accesos a ficheros y/o recursos del sistema operativo, etc. 


7.2.1 Interceptación de comunicaciones 


En algunos casos, como el caso de la red, es posible llevarlo a cabo sin 
interactuar con el proceso, ya que se puede simplemente escuchar el tráfico de la red, 
incluso desde un ordenador diferente al ordenador que ejecuta el proceso a analizar. 





7 Peap 


Pcap es un API para la captura de paquetes. En entornos Unix se conoce 
como libpeap, mientras que la versión adaptada para Windows de libpeap 
se conoce como WinPeap. 

Tanto libpcap y WinPcap pueden ser utilizados por un programa para 
capturar los paquetes que viajan por toda la red y, en las versiones más 
recientes, para transmitir los paquetes en la capa de enlace de una red, 
así como para conseguir una lista de las interfaces de red que se pueden 
utilizar para interceptar y/o transmitir tráfico. 





Estas librerías son los motores de captura de paquetes y filtración de muchas 
herramientas de código abierto y productos comerciales que existen, 
incluyendo analizadores de protocolo, monitores de la red, sistemas de 
detección de intrusos en la red, programas de captura de las tramas de red 
(packet sniffers), generadores de tráfico y optimizadores de red. 


F tcpdump 

Esta herramienta de linea de comandos que hace uso de la librería libpcap, 
se utiliza para interceptar el tráfico de red y mostrar en tiempo real los 
paquetes transmitidos y recibidos en la red a la que el ordenador que lo 
ejecuta, esté conectado. 
Funciona en la mayoría de los sistemas operativos UNIX: Linux, Solaris, 
BSD, Mac OS X, HP-UX y AIX entre otros. Existe una adaptación de 
tcpdump para los sistemas Microsoft Windows que se llama WinDump y 
que hace uso de la biblioteca Winpcap. 
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El usuario puede aplicar varios filtros para que sea más limpia la salida. 
Un filtro es una expresión que va detrás de las opciones y que nos permite 
seleccionar los paquetes que estamos buscando. En ausencia de ésta, el 
tcpdump volcará todo el tráfico que vea el adaptador de red seleccionado. 


V Wireshark 
Antes conocido como Ethereal, es un analizador de protocolos utilizado 
para realizar análisis y solucionar problemas en redes de comunicaciones, 
para desarrollo de sofware y protocolos, y como una herramienta 
didáctica. Cuenta con todas las características estándar de un analizador 
de protocolos, 

La funcionalidad que provee es similar a la de tcpdump, pero añade 
una interfaz gráfica y muchas opciones de organización y filtrado de 
información: 


аавв вите ш 


£ er maragan гїн, эе mores Бор, (р, ит ныт. мишук О) 





Así permite ver todo el tráfico que pasa а través de una red (usualmente 
una red ethernet, aunque es compatible con algunas otras) estableciendo 
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la configuración en modo promiscuo. También incluye una versión 
basada en texto llamada tshark. 


Permite examinar datos de una red activa o de un archivo de captura 
salvado en disco. Se puede analizar la información capturada, a través de 
los detalles y sumarios por cada paquete. Wireshark incluye un completo 
lenguaje para filtrar lo que queremos ver y la habilidad de mostrar el flujo 
reconstruido de una sesión de TCP. 


Wireshark es sofiware libre, y se ejecuta sobre la mayoria de sistemas 
operativos Unix y compatibles, incluyendo Linux, Solaris, FreeBSD, 
NetBSD, OpenBSD, Android, y Mac OS X, asi como en Microsoft 
Windows. 


7.2.2 Monitorización de funciones del sistema 


En otros casos, es posible interceptar las llamadas a funciones de las librerias 
del sistema o de terceros, asi como el envio de eventos o mensajes, utilizadas por 
el proceso para registrar la actividad relacionada con él. El código que maneja esta 
interceptación y monitoriza o manipula los argumentos y/o eventos, se conoce como 
hooking. 


Esta técnica es utilizada para muchos propósitos: depuración, para extender 
funcionalidades, capturar información de los periféricos, obtención de datos 
estadísticos y de rendimiento, ete. Estas técnicas son utilizadas a menudo por el 
malware, permitiéndoles guardar todo tipo de información, como las teclas pulsadas 
del teclado, movimientos del ratón para rellenar un campo numérico basado en 
botones desordenados (utilizado por los bancos), etc. 


Para ello o bien se inserta el hook en las librerías del sistema, o bien es posible 
hacerlo en la direcciones de invocación a las mismas desde el proceso, modificando 
la IAT del proceso. 





F LD_PRELOAD 


Tal y como se ha visto en unidades anteriores, es posible indicarle 
al cargador dinámico qué funciones debe cargar para resolver las 
dependencias y poder utilizar las funciones descadas no incluidas en el 
proceso, El cargador dinámico entre sus muchas configuraciones, tiene la 
variable LD_PRELOAD de entorno interesante para temas de hooking. 


La lista de librerías introducida en esta variable de entorno por el usuario, 
será cargada antes que ninguna otra del sistema en cl momento de la 





REVERSING. INGENIERÍA INVERSA ORAMA 


carga dinámica del proceso. Esto se utiliza para sobrescribir funciones de 
librerias compartidas. 


La librería se compilaría como una librería dinámica normal que 





contuviera la función a reemplazar. Lues 
estableciendo en la variable LD_PRELOAD el nombre de la libreria y/o 


ruta completa: 


ptrace (Process Trace) es una llamada al sistema disponible en varios 


о se invocaría el programa 


F ptrace 


sistemas operativos Unix/Linux. Mediante el uso de ptrace un proceso 


puede controlar a otro, lo 





al que controla poder inspeccionar 






ue permite 
y manipular el estado inter 





o del proceso controlado. ptrace es utilizado 
por los depuradores de código y otras herramientas de análisis de código. 





principalmente como ayudas para el desarrollo de software 


Esta funcionalidad ha permitido implementar programas de línea de 
comandos que monitorizan y registran las invocaciones a funciones de 


librerías externas con Itrace: 





Y las invocaciones a funciones del sistema asi como eventos con strace: 
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Más adelante, en esta misma unidad, entraremos en detalle sobre pirace, 
al explicar los depuradores de código. 


PAPI Monitor Filter 


Esta herramienta para Windows no es la mejor ni la única, pero funciona 
bastante bien y tiene una gran recopilación de API a monitorizar. Su 
funcionamiento es sencillo: selecciona las API a monitorizar, se puede 
hacer manualmente navegando por sus categorías: 








Y luego se inicia el proceso, pudiéndose ver el contenido de la información 
interccptada, como cn el siguiente caso para ReadFile: 
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Los filtros pueden ser guardados e importados más tarde. La herramienta 
de uso libre y su página oficial es esta: 


Y hup:/hwwwerohitab.com/apimonitor 


F Sysinternals 


SysInternals están especializados en monitorización de eventos y librerias 
de Microsoft Windows, hasta el punto que éste terminó comprándoles al 
disponer de herramientas completas y perfectamente estables, como por 
ejemplo el explorador de procesos, mucho más completo que el hasta 
entonces ofrecido por Microsoft en sus productos Windows. De entre sus 
muchas herramientas vamos a destacar Process Monitor: 


Y https: /hechnetmicrosofi.com/en-us/library/bb896645.aspx 


Process Monitor, o procmon, como se le conoce, es una herramienta 
avanzada de monitorización para Windows que tiene la capacidad 
de monitorizar el registro del sistema, el sistema de ficheros, las 
comunicaciones de red, la actividad de los procesos incluidas la actividad 
de sus diferentes hilos. Para ofrecerlo se combina con las herramientas 
FileMon y RegMon. 


Aunque es capaz de interceptar mucha información, no es capaz de 
interecptarla toda. Por ejemplo, no puede acceder a la actividad de los 
drivers de dispositivo, esto limita la capacidad para analizar rootkits. 
Tampoco es capaz de interceptar ciertas llamadas al interfaz gráfico de 
usuario como SerlVindowsHookEx. Tampoco es capaz de capturar el 
tráfico de red, de manera tan compacta y fiable, como se puede hacer con 
WireShark. 


Esta herramienta monitoriza todas las llamadas al sistema, por lo que 
se pueden producir más de 50.000 eventos por minuto; esto haría de la 
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herramienta algo poco práctico. Es por ello que permite la utilización de 
filtros para poder monitorizar solo lo que se desee, diferenciando entre 
origen del evento, proceso, ete. 





La siguiente imagen muestra la ventana principal y algunos eventos 
capturados: 


z 


= ыт мо Мы тш Шш э 
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Existen muchas más herramientas para este tipo de tareas, pero sin duda las 
herramientas de SysIntenals son un referente. 


7.3 CAJA BLANCA: DEPURADORES DE CÓDIGO 








Los depuradores de código permiten cargar el proceso en memoria tomando 
el control completamente del mismo. El depurador es capaz de preparar el entorno 
para lanzar la ejecución del proceso, y parar cuando se considere necesario, 
momento en el que se podrá consultar el estado de los registros, la memoria y todo 
lo relacionado con el proceso. Para más detalles vamos a explicar los depuradores en 
sistemas Linux y Windows. 
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PUNTOS DE INTERRUPCIÓN 


Antes de adentrarnos en los detalles de implementación de los depuradores 
de código para los diferentes sistemas operativos, vamos a comentar los detalles de 
implementación de los puntos de interrupción que son 
operativo. 





enerales a cualquier sistema 


Los depuradores utilizan los puntos de interrupción para permitir al usuario 
detener la ejecución del proceso trazado en diferentes puntos de manea interactiva y 
dinámica. Para ello hacen uso de varios tipos de puntos de interrupción y cada uno 
de ellos se implementa de diferentes formas. A continuación se explican los detalles: 


F Software BreakPoints 





Este tipo de punto de interrupción se lleva a cabo modificando el código 
ensamblador. Para ello sc hace uso de la instrucción de ensamblador INT3 
cuyo opcode en hexadecimal es OxCC. No confundir con la instrucción 
INT 3 cuya codificación en hexadecimal es 0xCD 0x03 y que, como se 
observa, ocupa dos bytes en lugar de uno. Aunque ambas instrucciones 
hacen lo mismo, OxCC al ocupar tan solo un byte es más versátil a la 
hora de inyectarlo en cualquier zona del código. Cuando el usuario quiere 





establecer un punto de interrupción en una zona concreta, el depurador 
lo que hace es sustituir el primer byte de esta instrucción por OXCC y 
almacena ese byte en una tabla junto con la dirección donde se sustituyó, 


00401130>555 PUSH EBP 
00401131 .89ES MOVEBPESP 
00401133 -83EC 14 SUBESPIG 
00401136 6A0 PUSHI 


Si descáramos establecer un punto de interrupción en la dirección 
00401131, se sustituiria el byte 0x89 por el byte OXCC y el código 


quedaría así 
00401130>555 РЫЅНЕВР 
омопз1 CC NTH 
00401132 ESS IN EAX83 
00401134 LEC INALDX 


00401135 -146A  ADCALSA 
00401137 -OIFF ADD EDLEDI 


Libro encontrado en: 
eybooks.com 
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Como se puede ver, al sustituir el byte y ser interpretable por el 
desensamblador, interpretaría el código de diferente manera. Por eso es 
importante que cuando se alcance csa dirección y se ejecute INT3, que 
provocará la excepción que capturará el depurador y mediante la cual 
sabrá que el proceso de ha interrumpido, debe llevar a cabo la sustitución 
en orden inverso, para poder ejecutar el código exactamente igual que al 
inicio. 


Para poder llevar a cabo estas sustituciones, los depuradores de código 
mantienen una tabla como la siguiente: 


Y la tabla de Software BreakPoints quedaría asi 


р Direcció EN 





Este tipo de puntos de interrupción son ilimitados, y depende de las 
restricciones del propio depurador a la hora de limitar su creación. 


Y Hardware BreakPoints 


Los puntos de interrupción de tipo hardware, utilizan unos registros 
del procesador para llevar a cabo la interrupción. Los registros son los 
denominados Debug Regísters (DRO-DR7). Y se utilizan de la siguiente 
forma: 


+ DR0-DR3: se usan рага almacenar la dirección de memoria en la que 
se desea interrumpir la ejecución al cumplir con la condición de DR7 

+ DRS-DR6: están reservados y no pueden ser utilizados. 

+ DR]: establece la condición con la que debe interrumpirse la 


ejecución. Estas condiciones están relacionadas con las dire 
almacenadas en los registros DRO-DR3: 





ciones 


= Interrumpir cuando una instrucción se esté ejecutando en una 
dirección de las almacenadas. 


= Interrumpir cuando se escriba algún dato en alguna de las 
direcciones almacenadas. 


= Interrumpir cuando se lea o escriba pero no se ejecute ninguna 
instrucción en alguna de las direcciones almacenadas. 


Las interrupciones de un paso (single step) se llevan a cabo mediante la 
INTL 
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Por su estructura, solo pueden utilizarse cuatro Hardware BreakPoints 
a la vez, pero son muy potentes, rápidos y fiables, sobre todo cuando se 
trata de analizar malware u otro tipo de software que no desee ser trazado. 


Y Memory BreakPoints 


Aunque con los Hardware BreakPoints se pueden establecer puntos de 
interrupción a varias direcciones de memoria, el usuario puede querer 
marcar una zona de memoria más extensa con la que interrumpir el 
proceso cuando sea accedida. Para esto, se utilizan los permisos de las 
regiones. De esta forma si se quiere interrumpir en caso de ser leída una 
región, se le quita el permiso de lectura, y al tratar de leer en esa región, 
el sistema operativo lanzará una excepción de violación de acceso al 
tratar de leer, momento en el cuál el depurador gestionará esa excepción 
modificando los permisos y dando el control al usuario. Con este método 
se pueden establecer tres tipos de permisos: lectura, escritura y ejecución. 


DEPURACIÓN EN MODO KERNEL Y USER-SPACE 





Los procesadores disponen de cuatro anillos de ejecución que utilizan para 
aislar la ejecución en cada uno de ellos, e impedir así que un código ejecutado en un 
anillo pueda interactuar con datos contenidos en otro de los anillos, a menos que se 
haga por los métodos destinados para ello. Estos métodos controlan los permisos y 
condiciones que deben ser utilizados para poder llevarlo a cabo sin riesgo. 


Los sistemas operativos se ejecutan en dos anillos distintos: 


F RING 0- KERNEL 


El kernel o núcleo del sistema operativo, es el encargado de interactuar 
de manera directa con el hardware y sus especificaciones. En esta capa 
es donde se implementan y ejecutan los drivers de dispositivos, así como 
las partes del sistema operativo que gestionan la memoria, dispositivos 
de almacenamiento, etc. 


Esta capa implementa las funcionalidades necesarias para proporcionar 
al usuario final una abstracción de los mismos y poder utilizar distintos 
sistemas de ficheros mediante las funciones estándar como read(J/rrite() 
con independencia de que tipo de dispositivo de almacenamiento se 
utilice finalmente. 


También es el encargado de gestionar los recursos de manera eficiente, 
con planificadores de tarcas, gestor de recursos y otras herramientas. Esto 
significa que la multitarea es una funcionalidad del sistema operativo, 
implementado por cl kernel, por lo que este se ejecuta de manera no 
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concurrente, es decir en un solo “proceso”. la hora de depurar el código, 
esto proporciona ventajas e inconvenientes. Por ejemplo, a la hora de 
analizar malware, si se puede depurar en RING 0, se tiene la certeza 
de que no habrá ningún otro proceso paralelo entorpeciendo nuestras 
acciones. Por otro lado, al depurar en RING 0, el sistema operativo se 
interrumpirá cuando estemos depurándolo, y no scrá posible interactuar 
con el sistema operativo trazado, es decir, que no será posible ni mover 
el ratón ya que las funciones gráficas estarán a la espera de que toque su 
tumo para refrescar la imagen, y su turno no llegará mientras estemos 
interrumpidos depurando en modo RING 0. 


Es por esto que la forma habitual de depurar RING Û es mediante otra 
máquina que se conecta por serie a la máquina a depurar y tras indicarle 
al sistema operativo que se quiere depurar, nos permitirá interrumpir el 
proceso. 


Hoy día esto no supone ningún inconveniente, ya que podemos hacer uso 
de máquinas virtuales y podremos acceder desde la máquina anfitrión a 
la máquina a trazar sin ningún problema. El siguiente enlace muestra un 
ejemplo de cómo es posible hacerlo para depurar el kernel de un Windows: 


Y https://msdn.microsofi.com/en-us/libraryhvindows/hardware/ 
Й538143%28у=уз.85%29.азрх 

En Unix/Linux el depurador en RING 0 por defecto es gdb. En Windows 

el depurador más utilizado para esta capa es WinDbg. 


F RING3-, 


En esta capa es donde se llevan a cabo todas las acciones del usuario del 
sistema operativo. Este solo puede acceder a los dispositivos a través de 
los recursos que el kernel le haya proporcionado. Por ejemplo si se desca 
acceder a un fichero se debe hacer a través de las funciones read ()/write() 
que son las encargadas de pasarle al kernel la información del usuario 
para que este, en función del driver del dispositivo de almacenamiento en 
cuestión, realice unas acciones u otras. 


En este anillo si hay concurrencia, por lo que varios procesos con varios 
hilos son ejecutados concurrentemente. Esto quiere decir que aunque 
se puede interrumpir la ejecución de un proceso al adjuntarnos con un 
depurador de código, otros procesos (entre ellos el propio depurador de 
código, la interfaz gráfica, etc.) pueden llevar a cabo acciones. 


Este tipo de depuración, aunque es más versátil y cómoda, no es el más 
potente. Sin embargo la mayor parte de trabajos de ingeniería inversa se 
realizan en esta capa. 
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istemas operativos Unix/Linux el depurador utilizado para RING 3 
es gdb. Y en sistemas Windows ha venido reinando OllyDbg, aunque 
también puede utilizarse WinDbg. 


7.3.1 Depuradores de código en Linux 


CONCEPTOS BÁSICOS 


Generalmente los depuradores en sistemas Linux están basados en el uso de 
ptrace. Como ya indicamos antes, ptrace (Process Trace) es una llamada al sistema 
disponible en varios sistemas operativos Unix/Linux. Mediante el uso de ptrace un 
proceso puede controlar a otro, lo que permite al que controla, poder inspeccionar y 
manipular el estado interno del proceso controlado. En el manual del desarrollador 
se encuentran todos los detalles sobre prrace y puede consultarse aquí: 





Y hp:/man?.orgllimux/man-pages/man2 ptrace-2.html 


Como se puede observar el funcionamiento en sí es muy sencillo, 


Hinclude <sys/ptrace.t> 
Jong рїтасе[ейш ptrace request request, pidt pid, void 
Жаййг, void *datal: 


Se hace una llamada al sistema indicando el identificador del proceso pid y 
se dice que se quiere hacer con ese proceso, request. Una vez que un proceso ha sido 
trazado por ptrace, todos los eventos serán enviados al proceso trazador, via wait) o 
waitpid(), incluso si el proceso trazado no está gestionando dichos eventos. 








Un proceso puede iniciar el trazado invocando a fork(2) y luego siguiendo el 
flujo del programa tras comprobar si está siendo trazado con el request = PTRACE_ 
TRACEME. 





Otra forma sería adjuntarse al proceso ya ejecutado; esto se hace con el 
request = PTRACE_ATTACH. 


Si la opción PTRACE_O_TRACEEXEC no está establecida, al ejecutarse 
un execve se generaría una señal que será interceptada por el proceso trazador, para 
darle la oportunidad de trazar también estos nuevos procesos. La señal utilizada en 
las trazas para interactuar con el proceso trazador es SIGTRAP. Esta señal es activada 
para que el proceso trazador pueda acceder al proceso trazado en los momentos 
necesarios. 
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Una vez recibida la señal de interrupción, el proceso trazado estará parado 


y hay que elegir qué hacer con él. No vamos a explicar todas las peticiones que se 
pueden realizar con pirace, pero sí vamos a explicar algunas interesantes desde el 
punto de vista de depuración de código, e importantes a la hora de implementar un 
depurador de código. Tenemos varias opciones, dependiendo del parámetro request 


que pasemos: 


Y PTRACE_CONT 
Hace que el proceso con identificador pid continúe hasta nueva orden 
(recepción de una señal por ejemplo). addr se ignora y data (si es distinto 
de 0) indica una señal que se le pasará al hijo cuando inicie su ejecución. 


Y PTRACE SYSCALL 


Exactamente igual que PTRACE_CONT, pero hasta el inicio o salida de 
una llamada al sistema. Esto es básicamente lo que utiliza el comando 
strace para registrar todas las llamadas a sistemas con sus argumentos. 


F PTRACE_SINGLESTEP 


Se utiliza para llevar a cabo la depuración paso a paso (step-by-step), 
donde se envía una señal SIGTRAP cada vez que el procesador ejecuta 
una instrucción ensamblador. 





Y PTRACE_GETREGS / PTRACE_SETREGS 
Leer/escribir los registros del procesador. Se pasa un puntero a una 
estructura de tipo user_regs_struct сп el parámetro data. 

Y PTRACE_POKETEXT/PTRACE_POKEDATA 
Permite escribir en el espacio de instrucciones/datos del proceso, en la 
dirección indicada por addr el valor indicado por data. 

F PTRACE_PEEKTEXT/PTRACE_PEEKDATA 


Como el anterior, pero leyendo de la dirección addr y devolviendo el 
valor leido. Hay que tener cuidado pues aquí -1 es un valor válido, y para 
saber si la llamada dio error hay que poner ermo=0 antes de llamarla, y 
comprobar que siga siendo 0 después. 


7 РТКАСЕ КІШ. 
Manda un SIGKILL al hijo para terminar el proceso. 
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Con estos request se pueden implementar las funcionalidades necesarias 
requeridas por un depurador de código. 


A modo de ejemplo se muestra el código fuente de un ejemplo en C que 
traza un proceso y muestra el valor de los registros en cada ejecución de instrucción 





Como se puede ver en la imagen, primero se invoca al fork() para poder 








ejecutar el proceso con execve() más adelante. Tras el fork el proceso comprueba si 





se está trazando o no para saber si es el hijo o el padre en la línea 13. Tras ejecutar un 





nuevo proceso con exevp, se esperan los eventos con waitpid() en un bucle infinito, 


istros (linea 29) y lueg 






Una vez se pare en el bucle, primero se leen los re 





le indica a ptrace que vuelva a producir una señal cuando se ejecuta la siguiente 





instrucción (línea 35). Si ejecutamos este programa para analizar /bin/s, se vería lo 








nte: 


Libro encontrado en: 
eybooks.com 


tuto 7. ANÁLISIS DINÁMICO. DEPURADORES DE CÓDIGO 285 


Estamos viendo el estado de los registros en cada instrucción ejecutada. 


Si queremos hacer algo parecido a strace, pero con la llamada a sistema 


), podríamos compilar un fuente como el siguiente: 
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Como se puede observar, lo único que cambia, es que en lugar de imprimir 
siempre los res 





stros, lo hacemos solo si EAX vale SYS_stat, que es la syscall 

utilizada previamente a acceder a un fichero. Y la ejecución se detiene no en cada 

dor (PTRACE_SINGLESTEP del ejemplo anterior) sino en la 
li (PTRACE_SYSCALL) 





strucción del proces 
entrada y salida de una sys 








Si ejecutamos este pequeño depurador de código con el comando /bin/ls se 
observa lo si 





jente: 





Se pueden ver los registros de cada entrada y salida de la llamada de sistema 





маң). 


DEPURADORES DE CÓDIGO 


El depurador p 
екет). Este potente depurador de códig 


excelencia bajo entomos Unix/Linux es gdb (GNL 





Debu 


trazado de manera interactiva y estable. 





permite interactuar con el proceso 


Ya hemos hecho uso de este 





urador en unidades anteriores, sin embargo 


vamos a comentar aquí algunos detalles básicos de funcionamiento sobre el depurador 





para que el lector pueda adentrarse un poco en el uso de esta herramienta. Para ello 
vamos a compilar el siguiente código: 
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Y vamos a depurarlo con gdb de la siguiente forma: 
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En primer lugar hemos ejecutado gdb con cl programa a depurar como 





mento, y luego hemos establecido un punto de interrupción en la función main(). 
De esta forma cuando ejecutamos el comando run se detiene en la función maín. 
En e 





e instante podemos consultar los registros. Si se quies 





e ver el código fuente, 
se puede o bien indicar que se mues 





en el contenido de la dirección apuntada por 
Seip en forma de 10 instrucciones (x/10í Seip), o simplemente se puede utilizar el 
comando disassemble: 





Si se quiere visualizar en sintaxis Intel se puede hacer lo siguiente: 
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Como se puede observar, tras establecer el tipo de sintaxis, el código 
ensamblador se ve según esta sintaxis. Para poder avanzar instrucción a instrucción, 
ejecutamos “sf” y si simplemente pulsamos Intro, se ejecuta la última orden dada 
a gdb. S 


aumentando. De hecho, al mostrar el desensamblado se ve como Seip apunta a varias 








ve como hay un par de líneas en blanco y sin embargo la dirección va 








instrucciones hacia adelante. Finalmente para salir, 





jecuta la orden “y 


Hay muchísimos comandos, y mucha documentación al respecto, desde 


manuales oficiales: 


/ hitp:lheww: gnu org/sofiware/gdh/documenta 








ORAMA 


Hasta tablas con comandos más utilizados: 


А htip:/idarkdust 
L hitp:llusersece 


‘20Sheet.pdf 





Se recomienda profundizar en su uso, que aunque pueda imponer en un 
principio, con la práctica se domina y resulta muy sencillo y útil. 








Este depurador permite la ejecución de script y comandos en lenguaje 





Python. Esto aporta una gran potencia a las 
el mundo de la explotación de 


vulnerabilidade 





depuración. Por ejemplo, en 








r overflows (exploiting) y la investig 









Y hups://github.com/longld/peda 


Si abrimos el códi 





anterior con este script cargado veremos lo siguiente: 
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Con esta nueva vista se ve mucha más información, registros, código y 
pila todo a la vez, con colores y resolviendo cadenas o direcciones indirectas. Se 
recomienda ver la documentación de este gran script para experimentar con él. 


Como se puede ver por la salida, este script ha sido utilizado en unidades 
anteriores para mostrar el código ensamblador. 


7.3.2 Depuradores de código en Windows 


Eneste apartado vamos a verlos depuradores de código en sistemas Windows. 
Estos difieren bastante en cuanto a la manera en la que el usuario interactúa con el 
sistema para llevar a cabo las tareas de trazado. Sin embargo el funcionamiento y 
utilización final son más o menos iguales. 


CONCEPTOS BÁSICOS 


Los depuradores en Windows hacen uso del API del sistema operativo para 
llevar a cabo sus acciones. No es lo mismo abrir un proceso para ser depurado, que 
adjuntarse a un proceso una vez ya ha sido iniciado. En el primer caso, el depurador 
es capaz de trazar todas las instrucciones del mismo desde cl inicio. Mientras que si 
nos adjuntamos, solo vamos a poder trazar las instrucciones posteriores al instante 
еп que nos adjuntamos al proceso activo. 


En cuanto a cómo se implementa esta traza, también hay diferencias entre las 
dos formas explicadas anteriormente. En el primer caso, donde se abre un proceso 
para ser depurado, se utiliza la función del sistema: 


BOOL NIMAPI Cresteprocess ( 


IpCurrensDirectery, 
IpStartupInto, 
ProcessInformation 
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Donde se le indica que queremos que el proceso pueda ser depurado, esto 
se hace estableciendo dwCreationFlags a 0x00000001 (DEBUG_ PROCESS) e 
indicando en las estructuras /pStartupInfo y IpProcessInformation la manera en la 
que queremos que el proceso sea abierto. 


En el segundo caso, es decir, si se procede a adjuntarse al proceso en 
ejecución, lo primero que debemos hacer es obtener el handle del proceso. Para ello 
podemos utilizar la siguiente función del sistema: 





HANDLE ЖІНАРІ Ора 
—In_ DWORD dwDesiredāccess, 


лп вост bInherstiandio, 


-In DRORD dwProcessId 











Donde se deberá proporcionar el PID del proceso enel parámetro dwProcessld 
y establecer el parámetro dwDesiredAccess a PROCESS_ALL_ACCESS. Tras esta 
Operación podremos adjuntarnos al proceso con esta otra función del sistema: 





SOOL NIMAPI Debugactiveproce: 


3n_ DMOSD duerocesszd 








De esta forma, el sistema operativo entiende que el proceso encargado de 
interceptar los eventos del proceso con dicho PID, es el proceso que ha invocado 
esta función. Por lo que al producirse cualquier evento se le pasará directamente 
a este proceso trazador aunque el proceso trazado no los intercepte. El trazador o 
depurador de código debe capturar los eventos que produzca, y para ello utiliza la 





BOOL WIN: 
—Out_ LPDEBUG_EVENT 
In DWORD 

Ñ 
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Donde se enviará en el parámetro [pDebugEvent el evento en cuestión 
capturado. Una vez llevadas a cabo las acciones necesarias por el depurador en ese 
instante, se puede continuar la ejecución con la función del sistema: 


EOOL WINAPI Continuenebugevent ( 
—In_ DWORD duProcessId, 
—In_ DWORD dwThreadió, 
_In_ ONORO decontimuestarus 








Donde se deberá establecer el estado en el que se continúa, por defecto 
DBG_CONTINUE o DBG_EXCEPTION_NOT_HANDLED que significa que no 
se ha podido manejar la excepción y el sistema operativo arrojará la famosa ventana 
de “Ha ocurrido un error”. 


а 7 
J Windows ire Wier has stopped woring 
AARÓN 
== 





> Send Report 
$ Do Not Send Report 








СЕРУ 





Ahora que ya sabemos cómo se puede establecer el bucle de manejo de 
excepciones para los eventos, vamos a ver cómo interactuar con los registros del 
proceso trazado. Para ello se utilizará la función del sistema: 


HANDLE WINAPI CpenThread( 
—In_ DWORD dwDesiredāccess, 
—īn_ BOOL bInheritkandle, 
—In_ DWORD dwThreadīd 
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Esta función es muy parecida a OpenProcess() excepto que en lugar de 
solicitar el id de proceso solicita el id del hilo TID (thread identifier). Aunque el 
proceso no sea multiproceso, se está ejecutando al menos un hilo, el hilo principal. 
Para enumerar los identificadores de hilos podemos utilizar esta función del sistema: 


HANDLE WINAP] CreateToclhelp32Snapshot | 
_la_ DNORD dxPlags, 
—In_ DWORD th: 
lo 





El parámetro dwFlags se utiliza para indicar qué tipo de información se quiere 
Obtener, proceso, módulos, hilos, etc. En nuestro caso descamos obtener los hilos, 
por lo que establecemos ese parámetro con la constante 7A32CS_SNAPTHREAD = 
0х00000004. En el parámetro 1h32ProcessId se indica cl identificador de proceso. 
Si la función acaba satisfactoriamente, se devuelve un handle a un objeto snapshot, 


Para poder interactuar directamente con los registros, debemos dar con el 
hilo en cuestión. Para esto debemos visitar todos los hilos hasta dar con el que nos 
interese, Si el proceso no es multitarea, tan solo habrá uno. Para esto vamos a utilizar 
la función del sistema: 


BOOL WINAPI Thrcad325ir: 
In. нашия hsnapshot, 
READENTRY32 1pte 








Donde le pasamos el objeto snapshot obtenido anteriormente por el parámetro 
Snapshot. Si no se ha encontrado el hilo y se desea iterar en busca del mismo, se 
puede utilizar la siguiente función del sistema: 


BOOL WINAPI Thr=ad32Next ( 
In. RANDLE hanapshot, 
_Out_ IPTERERDENTRY32 Ipte 








Una vez tenemos el handle del hilo, podemos obtener o establecer los datos 
en el contexto del hilo. Рага interactuar con los registros, podemos leer los datos o 
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escribir en ellos, para lo que se utilizará GetThreadContext() o SetThreadContext() 
respectivamente, cuyas definiciones son estas: 


EOOL WINAPI GetIhreadcontext ( 
Ів. HANDLE тыгай, 


_Hmour_ 1SCONTEXT Ipcontext 





El parámetro [pContext, contiene los valores de los registros leidos del hilo, 
o los valores de los registros a establecer en el hilo. 


Una vez estamos depurando un proceso, la función del sistema que se utiliza 
рага interpretar los eventos recibidos, es: 





#aitFerî 





EOOL WINAI bugEvent ( 
_Out_ LPDESUG_SVEST Ipoebugevent, 
amilliseconds 





El parámetro IpDebugEvent, contiene una estructura de eventos que indica 
que tipo de evento es. En función de esto ya se pueden llevar a cabo las acciones que 
se consideren. 


Para una mayor comprensión sobre la implementación de un depurador en 
Windows, se recomienda que se analice el código del depurador de código escrito en 
Python, por Pedram Amini, PyDBG: 


4 htips:/lgithub.com/OpenRCE/pydbg 


O este otro escrito en C/C++: 


Y hup:/www.codeproject.com/Articles/43682/Writing-a-basic-Windows- 
debugger 
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A continuación, a modo de ejemplo, se muestra la implementación en 


PyDbg, de un punto de interrupción por software utilizando la metodología explicada 
anteriormente: 


def bp set (self. айтыл, атша, тайа, talar) 





ar, cepto, sore, hatos 


тш» зел. эл 
eit. Sone peo ars) 


аа gs as e rs) 








таза шташ, Те, 


A nr, gu a, crio, reten, santo 





тшше рэ айе зз вгеөуагї и ша А аннан! 


retum saf? rt zirt) 


DEPURADORES DE CÓDIGO 





En entornos Window hay dos depuradores de código ampliamente utilizados, 
Ollydbg y WinDbg. 


F Ollydbg 


Este depurador de código solo es capaz de depurar código en RING 3, 
sin embargo sus funcionalidades lo hacen extremadamente potente. La 
versión 1 solo es capaz de depurar código en 32 bits, pero en la nueva 
versión 2 ya es posible depurar código de 64 bits. El código no es libre, 
unque hay empresas como Immunty Inc. que lo compraron para poder 
hacer su propia versión, Immunity Debugger: 


Y htp://debuggerimmunitrinc.com/ 





ORAMA 
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Esta versión del depurador diseñada principalmente para los investigadores 
des 
еп otros sectores, 





ridad y desarrolladores de exploits es, sin embargo, muy utilizada 


Su interactividad viene debida a que es posible utilizar scripts en Python 





para controlar el depurador. Esto ayuda enormemente a la hora de realizar 





tareas automáticas que manualmente serían extremadamente costosas. 


Para que el lector se pueda hacer una idea de la interfaz gráfica, a 
continuación se muestra un ejemplo de uso con el código fuente de la 





Hustración 25 compilado en Windows y cargado en Immunity Debugger 


I x ê I HII 1c 1k JF bz EA 


zen res 





Como se puede observar hay cuatro ventanas: 
+ Código: localizada arriba a la izquierda. Aquí es donde se va viendo 

el código en tiempo real, y se va desplazando hacia arriba conforme se 
er BreakPoints 
pulsando F2 cuando se esté sobre la instrucción deseada. Poner 





van ejecutando instrucciones. Aquí se pueden estables 


etiquetas pulsando *:” o comentarios pulsando “5”. Para la depuración 
se pueden ir pulsando las teclas F7 Step Into (instrucción a instrucción 
entrando en las funciones) FS Step Over (pasando por encima de 
las instrucciones CALL) o F9 para continuar la ejecución hasta el 
próximo BreakPoint, excepción o final del pre 





Laventanadecódi 





permitemodificarelcódigoencualquiermomento 
pulsando la barra espaciadora. De forma que se puede reparar, probar 
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código ahí mismo sin tener que recompilar. Para grabar los cambios, 
se debe pulsar con el botón derecho Copy to excctubale->Selection 
y en la ventana que sale otra vez botón derecho y Save File, Esto es 
пріо, 
que se quiera saber cómo se comporta una porción de cûdi 





realmente útil para multitud de escenarios. Рог еў el caso de 






20, pero Se 
tengan problemas a la hora de establecer BreakPoints. En ese caso, se 
accede al código, se modifica el código con la barra espaciadora y se 
о зе guarda y ejecuta sin el depurador de código. 





introduce INT3, lue: 





El sistema operativo al l 
depurador por defecto (JIT Just-In-Time Debugger) que lo abrirá y 
dejará pausado. 





ir a esa instrucción, enviará el proceso al 


+ Registros: aquí es donde se muestran los registros en tiempo real. 


Los registros que cambian de una ejecución a la siguiente, cambian de 





calor, para poder identificarlos fácilmente. Estos registros se pueden 


modificar en cualquier momento. 





© Dump: esta ventana se utiliza para volcar datos de memoria según la 
necesidad del usuario. Por ejemplo, en el caso que se vio en unidades 
anteriores, se puede utilizar para ver la LAT del binario: 





O cualquier estructura o datos en cualquier momento y de forma 
dinámica 





SRAMA 


Capitulo 7. ANÁLISIS DINÁMICO. DEPURADORES DE CÓDIGO 299 


+ Stack: en esta ventana se puede ver en tiempo real el estado de la 


pila. La primera dirección siempre apunta a ESP, y se va moviendo en 





función de si se modifica o no. Se puede poner fija si se quiere seguir 
el estado de una variable en concreto. También se pueden visualizar 
offset respecto a una dirección concreta, si se pincha dos veces sobre 


una dirección y se abre la columna para ver la dirección: 





Esto es extremadamente útil a la hora de depurar el estado de las 
variables de la pila. En concreto cuando se está tratando de analizar 
vulnerabilidades del tipo Stack Overflow, esto es muy práctico. 


Como se puede ver es extremadamente versátil, fácil e intuitivo de 





utilizar. En la parte de abajo tiene una barra de comandos donde se pueden 





ejecutar comandos en Python. Esto le dota de una gs 
en Python y ejecutarlos, en /mmunity 


ın potencia. También 








se pueden escribir programas 
Debugs 





a estos seript se les denominan PyCommands. 





FP Windbg 


Este depurador es sin duda el más importante en entornos Windows, tanto 
para RING 3 como para RING 0. Su interfaz es más parecida a gdb. Es 
decir, que se basa en l 

hacer con el ratón son totalmente limitadas. La apariencia de WinDbg 


ejecución de órdenes y las acciones que se pueden 





tras ser instalado es algo así: 
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ETTI 





Sin embargo, se puede configurar en cuanto a las ventanas que se quieren 





visualizar y los temas de colores, pudiendo fácilmente II 


apariencia así. 





ORAMA 
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Donde se observa que es posible tener la misma distribución que en 
OllyDbg, y que es posible modificar los colores para una visualización 
menos agresiva. El negro sobre fondo blanco cansa más rápidamente la 
vista que los fondos oscuros. 


Este depurador es extremadamente completo y permite automatizar 
todas las tareas, por lo que resulta de gran utilidad para labores de 
ingeniería inversa avanzadas, como pueden ser las investigaciones 
de vulnerabilidades, desarrollo de drivers y componentes del sistema 
operativo. 

El manual oficial de WinDbg muestra todo el conjunto de comandos 
disponibles en el siguiente enlace: 


S https://msdn.microsoft-com/en-us/library/vindows/hardware/ 
Й561306%28у=уз.85%29.азрх 


Aunque se pueden consultar una lista de comandos más utilizados 
agrupados por temas en el siguiente enlace: 


Y hutp:/Avindbg.info/doc/I-common-cmds.html 


Como último dato, comentar que es posible utilizar la potencia de un 
desensamblador como IDA Pro, conjuntamente a la potencia de detalles de la 
ejecución utilizando WinDbg como depurador de IDA Pro. En la página oficial de 
Hex-Rays se explica cómo utilizar este y otros: 


Y hups:/hrwhex-rays.com/products/ida/supporttutorials/debugging.shtml 


7.4 CUESTIONES RESUELTAS 





7.4.1 Enunciados 


1 





¿Qué depuradores de código pueden depurar código en RING3%: 
a. OllyDbg 

b. Immunity Debugger 

e. tepdump 

d. gdb 

e. Windbg 
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¿Qué depuradores de código pueden depurar código en RINGO?: 
a. OllyDbg 

b. Immunity Debugger 

€. tepdump 
d. gdb 

e. Windbg 

¿Con qué función del sistema se pueden enumerar los hilos de un 
proceso? 

a. CreateProcess 

b. OpenProcess 

e. WatiForDebugEvent 

d. CreateToolHelp32Snapshot 

e. OpenThrcad 


¿Con qué función del sistema se puede obtener el contexto de un hilo? 


a. GetThreadContext 
b. SetThreadContext 

e. Thread32First 

d. CreateToolHelp32Snapshot 
e. OpenThrcad 


. {Соп дие función llamada del sistema se puede depurar un proceso en 


Linux?: 


¿Con que función herramienta se pueden monitorizar las llamadas al 
sistema de un proceso en Linux?: 

a. strace 

b. Itrace 

c. ptrace 

d. gdb 

e. peap 
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7. ¿Con qué nombre se conocen a las pruebas realizadas sin conocimiento 
de la estructura y/o información interna”: 





a. Caja blanca 
b. Caja gris 
e. Caja azul 
d. Caja verde 
e. Ninguna de las anteriores 





8. ¿Con qué nombre se conoce a las pruebas realizadas con conocimiento de 
la estructura y/o información interna? 


а. Caja Blanca 
b. Caja Gris 

e. Caja Azul 

d. Caja Verde 

e. Ninguna de las anteriores 


9. El análisis estático no se centra en: 


a. Desensamblar el código objeto. 
b. Inspeccionar las funciones de librerias externas. 
e. Ejecutar código. 

d. Descifrar porciones de código. 


10.El análisis dinámico de comportamiento no se centra. 





a. Desensamblar cl código objeto. 
b. Inspeccionar las funciones de librerías externas. 
e. Ejecutar código. 

d. Monitorizar llamadas a librerías del sistema. 


7.4.2 Soluciones 
Lab de 


2d e 
.4 


5 
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7.5 EJERCICIOS PROPUESTOS 











1. Con las funciones del sistema comentadas aquí, tratar de implementar 
un depurador sencillo para Windows, que permita al usuario utilizar 
Sofiware Breakpoints: 


2. Con llas funciones del sistema comentadas aquí, tratar de implementar un 
depurador sencillo para Linux, que permita al usuario utilizar Software 
Breakpoints: 








APLICACIONES PRÁCTICAS 


Introducción 


En esta unidad didáctica se ponen en práctica todos los conocimientos 
adquiridos para llevara a cabo la resolución de tres casos prácticos: el análisis de 
una vulnerabilidad que se reproduce a partir de una prueba de concepto; el análisis 
de una aplicación para detectar funcionalidades ocultas; el análisis de una aplicación 
que maneja un tipo de ficheros binario cuyo formato es desconocido, para generar un 
fichero válido a partir del código del programa, sin disponer de ningún fichero con 
dicho formato de ejemplo. 


Objetivos 


Cuando el alumno haya concluido la unidad didáctica, será capaz de manejar 
depuradores derivados de Ollydbg para analizar desbordamientos de pila. Manejar 
IDA Pro para navegar por las funciones de una aplicación guiados por el flujo del 
programa, extraído del análisis dinámico efectuado sobre el programa a analizar. 
Analizar de manera estática un programa con /DA Pro, para analizar сі manejo de 
datos sobre el contenido de un fichero binario y poder así reconstruir el formato del 
fichero, pudiendo generar ficheros binarios válidos sin disponer de ninguno como 
ejemplo. 


8.1 PUNTO DE PARTIDA 








Esta última unidad pretende ser una ventana a la ingeniería inversa puesta 
en práctica en sus diferentes facetas. Si bien es posible mostrar por encima algunos 
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ejemplos de los distintos campos, scría imposible condensarlos en una solo unidad, 
y menos aún que queden claros todos los detalles. Sin embargo, aquí trataremos de 
que al menos el lector pueda hacerse una idea de cuál sería la operativa normal en 
este tipo de escenarios, 


Para ello se van a exponer distintos escenarios donde aplicar ingenieria 
inversa, se van a establecer los objetivos del mismo y por último se van a explicar 
los pasos a llevar a cabo para poder resolver el problema, pudiendo cumplir con los 
objetivos marcados. 


8.2 CASO PRÁCTICO 1: ANÁLISIS DE VULNERABILIDADES 


Objetivo 


En este ejercicio vamos a analizar una versión de software que se sabe es 
vulnerable partiendo de una prueba de concepto que consigue provocar una excepción 
en el programa, y a partir del cual utilizaremos un depurador de código para analizar 
dicha situación y no solo comprender a qué es debido, sino entender de qué manera 
podemos aprovechar esta situación para inyectar código ejecutable. Esto es conocido 
como explotación de la vulnerabilidad y sc considera un fallo grave de seguridad. 





Debido a que la explotación de la vulnerabilidad es toda una materia de 
estudio por sí sola, no vamos a entrar en esos detalles debido al carácter introductorio 
de este curso, solo vamos a mostrar de qué forma es posible utilizar un depurador de 
código para llevar a cabo estas acciones. 


Detalles 


El la versión vulnerable del software objetivo (VLC Media Player 0.8.6d) se 
puede obtener del siguiente enlace 





Y Inp:/filehippo.com/download_vle_32/3516/ 


A modo informativo, se puede consultar las vulnerabilidades existentes en 
esa versión del software en CPE Details, de entre las que se indica la vulnerabilidad 
que vamos a tratar aquí CVE-2007-6681- 





М ирге 
id-9876/version_i 





evedetails.com/vulnerability-list/vendor_ic 
0729/ 


-5842/ргойис1_ 
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La prueba de concepto que provoca la excepción en el software se puede 
descargar de este otro enlace: 


4 htp://aluigi.ore/pochvlcboffsip 


Esta prueba de concepto consta de los siguientes ficheros: 


F vicbofavi 
F vicbof.ssa 


Tras a instalar el software, vamos a reproducir la excepción con la prueba de 
concepto (PoC — Proof of Concept) que se proporciona. Para ellos basta con pinchar 
dos veces sobre vlebofavi. Tras lo que se observa cómo se abre el VLC, pero se 
cierra automáticamente. Esto muestra cómo ha sucedido algo inesperado y el sistema 
operativo ha cerrado la instancia sin ninguna interacción por parte del usuario. 


Para más detalles vamos a adjuntamos con el depurador de código al 
proceso. Para ello utilizaremos Immunity Debugger, basado en OllyDbg, pero con 
funcionalidades especiales para la explotación de sofware. 





Ahora vamos a abrir el VLC, luego abrimos el depurador, pinchamos en 
File->Attach y seleccionamos el proceso que se identifica como VLC. Veremos 
¡cómo se carga el programa, y cuando pare le damos a Run (F9), pasamos al programa 
VLC, abrimos el fichero vichofaví y observamos que se salta el depurador con la 
siguiente ventana, indicando, en la parte inferior de la ventana, que se ha producido 
una excepción de escritura: 
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Si nos fijamos bien en el código ensamblador 77C44609 MOV BYTE PTR 
DS:[ESIJ,AL vemos que intenta copiar 0x41 en 0x028B0000, dirección que al 
parecer no ha sido asignada en la imagen d хо 








1 proce 


Para saber a 





nento pertenece esta dirección, vamos a la ventana 








Show Memory (Alt+M) y buscamos dicha dirección. Evidentemente no existe, pero 


justo la dirección anterior pertenece a la pila. Si observamos la pila, vemos que la 





cima de la pila (ESP) está en 0x02887754, asi que vamos a ver dónde acaba 





1 Ox28AFFFC 
observa bien, a continuación no hay nis 


Como se puede ver, finaliz 





“finaliza”, porque si se 





ma dirección más, solo un espacio en 
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negro. Esto indica que el registro £S/ apunta a una dirección fuera de la sección, la 
excepción se produce porque intenta escribir fuera de la sección de la pila (stack) 


Se puede observar, aunque en este curso no se ha podido entrar en los detalles 





de la implementación del manejo de por parte del sistema operativo, 
que se ha sobrescrito la dirección del manejador de excepciones (SEH — Structured 


Exception Handling) que contiene 0x41414141. Este manejador lo que hace es 


excepcion 








ejecutar el código alojado en la dirección apuntada por SEH en el momento de 


producirse una excepción, como en nuestro caso, que se ha producido una excepción 


de violación de segmento al tratar de escribir. Por ello si pasamos la excepción con 


hift+F9, debería intentar ejecutar código en 0x41414141 





J] Acces; viglaion when exscuting [41414141 ]- ге Shitet 7/FB/F3 to pass escepton to pogan 





Y si le volvemos a dar a Shift+F9 obtenemos la típica ventana de error 

















De esta forma ya sabemos que el error se produce al tratar de escribir una 
de “aes” en una dirección de memoria en la pila. Sabemos de 


unidades anteriores, que las variables almacenadas en la pila, son variables locales. 





cadena muy la 








Esto es un claro ejemplo de Stack Buffer Ov 
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Para concretar el tamaño del buffer, podemos calcular cuantas “aes” 
exactamente necesitamos para provocar la excepción. Para ello, nos vamos hasta el 
final de la pila, pinchamos dos veces sobre la última dirección y cuando se ponga la 
flecha, subimos hasta el inicio de la cadena de “aes” para ver a qué distancia está: 





bytes. Con este dato 





Como podemos ver en la imagen, está a 0x2: 





ya podríamos hacer un exploit que genere un fichero con la estructura necesaria 
para provocar la excepción, basándonos en la prucba de concepto vlcbof.ssa cuyo 


contenido se muestra a continuación 





Los caracteres especiales que se aprecian a continuación de Dialogue no 





son necesarios. Se pueden introducir directamente la cadena larga de “aes”, como 


se muestra en el siguiente código Python para generar un fichero como el mostrado 





anteriormente: 
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Si ejecutamos este fichero y abrimos el fichero vlcbofssa resultante, 
reproduciriamos la misma situación. 


A partir de aqui se puede sustituir la dirección SEH por una que apunte hacia 
un código ejecutable, sustituyendo alguna parte de las “acs” por bytes que, al ser 
interpretados como código, ejecuten código potencialmente malicioso, como puede 
ser la ejecución de un intérprete de comandos escuchando en algún puerto TCP, 








descargando algún malware, ete. Este tipo de código se conoce como shellcode. 


A modo didáctico, se puede consultar su explotación completa en el siguiente 
texto, escrito por el awtor del curso en un contexto mås informal, en el siguiente 
enlace: 


Y http://www.mediafire.com/download/mwnzyltzmjg 
2008 - Exploit_para_VLC_- _Boken.rar 


Solucion_al_ 








Concurso. 





8.3 CASO PRÁCTICO 2: ANÁLISIS DE FUNCIONALIDADES OCULTAS 


Objetivo 


En este ejercicio vamos a analizar un software, objeto de nuestro análisis, 
con la idea de analizar sus funcionalidades internas y con la finalidad de averiguar 
si existe alguna funcionalidad interna no documentada. En este caso, como es un 
sofware de ejemplo, no hay documentación del desarrollador, pero sí muestran 
mensajes con los comandos que se pueden utilizar. 
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Detalles 


En este ejercicio vamos a utilizar un software de ejemplo hecho desde cero 
e se muestra mi 





para esta unidad, y cuyo código fuen 





adelante. Es importante no 





consultar dicho código hasta que se haya finalizado el anålisis aqui expuesto. La 
finalidad de mostrar el código es, por un lado, comprobar que los tipos de datos y 
estructuras de códi 





g0 reconstruidas son correctas, y por otro lado, poder compilar 
dicho código y que el alumno trate de reproducir el ejercicio analizando y practicando 


lo que considere oportuno. 


En primer lugar vamos a ejecutar el binario a ver que muestra 





Como se puede observar se pone a la escucha en el puerto 12345, por lo 
que vamos a abrir una conexión contra ese puerto y vemos que muestra el si 





сте 





mensaje: 





Parece ser un servicio remoto de calculadora que realiza tan solo dos 


operaciones, sumas y restas. La ter 





era opción es la de salir. Vamos a probar las 
opciones para familiarizarnos y ver su funcionamiento: 
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Se ha marcado en rojo los valores introducidos por el usuario. El menú 





de opciones del programa solo permite 


introducidas mue: 





dichas operaciones, para el resto de letras 





а un mensaje de error estándar y de nuevo el menú. 








Ahora que ya conocemos el funcionamiento normal del programa, pasamos 





a su desensamblado para poder analizarlo estáticamente y ver qué información 






podemos obtener. Para el 





lo vamos a utilizar IDA Pro. Si no disponéis de una licencia, 





podéis utilizar la versión Freeware 5.0 que se puede descargar desde aquí 





Y, https://out7.hex-rays.com/files/idafreeS0.exe 
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Esta versión es para Windows y no utiliza el interfaz gráfico QUA, sin embargo 
para las tareas que vamos a llevar a cabo esta versión será suficiente. 


Tras abrir el binario con IDA vemos lo siguiente: 





La primera función que aparece en la vista es la función cuyo nombre ha 
establecido como start 





ORAMA Capítulo. APLICACIONES PRÁCTICAS 315 





A la izquierda se puede ver la lista de funciones con diferentes colores. Las 
funciones con color rosa son las funciones importadas de librerías dinámicas, es por 
sto que se ha podido obtener su nombre: 








Sin embargo, las funciones con fondo blanco que comienzan por sub_ son 
las funciones del programa que debemos analizar para ver su funcionamiento. En 
este ejemplo, cuyo código fuente no supera las 180 líncas, sería factible analizar cada 
una de las nueve funciones identificadas. Pero esto no es ni de lejos un escenario 
real, donde puede haber cientos de funciones y analizarlas todas conllevaria mucho 
tiempo y termina no siendo nada práctico. Para hacerse una idea, se emplaza al lector 
a abrir el ejecutable del ejercicio anterior y se enumeran las funciones existentes para 
poder ver la diferencia. 


En este momento es cuando uno se da cuenta que es necesario definir una 
estrategia clara para poder abordar estas tareas. Ya que el objetivo es analizar las 
funcionalidades, vamos a tratar de identificar la función que lleva a cabo la gestión 
de las opciones del menú de opciones. 
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Depende de la experiencia del investigador que lleva a cabo las tareas de 
ingenieria inversa; aquí es donde se abre un abanico muy amplio de estrategias a 
llevar a cabo. La recomendación es aplicar lo que al investigador le resulta más 
cómodo y donde se vea más fuerte. Es decir, si se conocen mejor las funciones 
de manejo de cadenas, será más lógico comenzar la búsqueda de cadenas de texto 
para identificar qué direcciones de código las utilizan. Si se comprenden mejor las 
funciones relacionadas con las redes de comunicaciones, lo más lógico es identificar 
las funciones que permiten enviar y recibir datos entre el cliente y el servidor. Si se 
conocen las estructuras de programación utilizadas para este tipo de programas, se 
tratará de detectar la función main(), y para identificar el típico bucle infinito que 
gestiona las conexiones del servidor, y de ahí ir analizando las funciones que se 
ejecutan, hasta llegar al otro bucle infinito que maneja las opciones introducidas por 
el cliente. O cualquier otro tipo de estrategias que puedan surgir. 





En este caso, vamos a optar en primer lugar, por identificar las cadenas de 
caracteres que se observan en el menú. Ya que cada vez que se introduce una opción 
vuelve a aparecer, esto indica que el código que gestiona las opciones contiene el 
código que envia el menú al cliente. 





En IDA se pueden enumerar todas las cadenas de caracteres del binario con 
La ventana de strings, que se puede abrir en el menú View->0Open Subviews->Strings 
o pulsando Shift+F12, donde veremos lo siguiente: 


EN 





Же пты 
Eror 2l asociar e! puerta de escucha. 





Las primeras cadenas son claramente lo que estábamos buscando: son 
los mensajes de texto que aparecen en el menù de opciones. También vemos 
otros mensajes de error, normalmente utilizados en el proceso de creación del 
socket y asociación del puerto a la interfaz de red. Por último podemos ver algo 
un tanto llamativo, un mensaje que hace referencia a una supuesta funcionalidad 
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de depuración. Esta funcionalidad sin embargo no está identificada en el menú de 





opciones. Podríamos ir directamente a esta zona del código, pero vamos a 
La estrategia marcada, identificar el códig 
opciones. Para ello vamos a pinchar dos veces sobre la primera cadena “Teclec su 
opción [AIB[Z]:” e iremos a la siguiente zona de códig 





guir con 





que gestiona las opciones del menú de 











Aquí se pueden ver más cadenas de texto, concretamente las que muestran 
el menú principal. En relación a la cadena que veníamos analizando, para ver en 
qué zona de código se utiliza, debemos mostrar las referencias cruzadas sobre ева 
dirección, para ello debemos pulsar Ctrl+X y veremos la siguiente ventana con un 
solo elemento: 





шеш м мт 





Si le damos a OK nos lleva al código en cuestión: 
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Vemos que básicamente lo que hace es invocar la función sprintf con unas 
cadenas de texto y cuyo primer argumento es el arg 





mento de la propia función, 
variable s. Esto lo sabemos ya que los argumentos de una función se almacenan 
en la pila en orden inverso, es decir para foo(1,2,3) se almacenarían 3, 2, 1 y luego 
invocaría a foo(), esto es siempre así cuando se usa la instrucción PUSH, aquí se usa 


MOV, pero si se observan los offsets cuya base es el registro ESP, 





mantiene esa 
alineación. También sabemos que las direcciones de variable que se acceden con el 
registro EBP como base y un desplazamiento positivo, son argumentos de la función. 
Con todo esto averig 





uamos que la variable s se proporciona como argumento a esta 
función y esta la utiliza para invocar sprintf con unas cadenas de texto. Es decir, 





se utiliza para copiar un texto a una variable. Como este texto es el del menú de 
opciones, vamos a nombrar a esta función menu. Para ello nos posicionamos o 
pinchamos sobre la palabra sub_80488DC, y ve 





-mos que se sombrean todas las 





Е 
5 
8 
E 
Я 
$ 
8 
8 
g 
© 
2 
8 
$ 
E 
5 
8 
8 
5 
е 
5 
3 
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En este momento, pulsamos N y nos aparece una ventana donde poder 


cambiar el nombre a la función. Escribimos y le damos alntro. Ahora 


vemos esto: 





vemos su nuevo 





Y en la lista de funciones del panel de la izquierd: 


nombre: 





[A Functions window 





Function name 


Line 19of62 
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Ahora vamos a reproducir el mismo proceso que hicimos con la cadena para 
saber desde dónde se invoca esta función. Para ello, una vez sobre el nombre de la 
función menu solo tenemos que volver a pulsar Ctrl+X y vemos la siguiente ventana: 











encia cruzada que tiene la dirección de esta función 
n la columna Text ya aparece 


Aparece la única refe 
que acabamos de renombrar. Como se puede observ 
con su nuevo nombre. Si le damos a OK nos lleva al código en cuestión: 








Nostración 26 


Aquí se ve la función que invoca la función menu(). Si observamos el bloque 
básico en cuestión: 
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iE 





Vemos cómo al final hace un salto condicional, cuyos comentarios 
son respecto a una tabla de la estructura de código switch. Y vemos cómo resta 
el valor 0x41 al registro ear. Si queremos ver las posibles codificaciones de este 
valor, pinchamos sobre 41% y lu 
codificaciones, entre las que se ve “4” a lo que podemos convertir si pulsamos la 
tecla R: 


con el botón der 





cho podemos ver diferentes 
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Como se puede deducir, esta es la primera opción del menú de opciones. 
Estamos sin duda en una parte muy interesante del programa. Es común utilizar 
switch para escoger entre diferentes funcionalidades, ya sea mediante un menú, 
como en este caso, o al realizar algún análisis léxico de una cadena de caracteres o 
binarios recibidos por red, ficheros, ete. 











En este punto vamos a ver cuántas opciones diferentes hay. Se puede ver a 
simple vista que hay cinco flechas que salen de ese bloque básico: cuatro flechas del 
bloque básico de la izquierda y uno más hacia el de la derecha: 





Si vamos más a la izquierda y vemos hacia donde apuntan esas dos flechas 
azules, vemos lo siguiente: 








En la izquierda *65,97'— Aa; y en la derecha *66, 98° = B,b. Este es el 
motivo de que las opciones de suma y resta del menú funcionen indistintamente de 
si se pone en mayúsculas o minúsculas. Con esto ya tenemos las dos funcionalidades 


documentadas. 








Vamos ahora hacia el lado de la derecha para ver qué otras opciones hay 
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Se pueden ver otros valores "90,122" = Z.z. Con esto tenemos localizada la 
opción para salir del menú. Ahora vamos a centramos en la última opción en cuyos 
comentarios indica que es la opción default del switch: 





Aquí se observa cómo se invoca la función _stremp() con la variable s 
сото primer argumento y una cadena de caracteres estática DEBUG como segundo 
argumento. En función del resultado saltará a un bloque básico u otro. La función 
_stremp() devuelve 0 en el caso de que las cadenas de los argumentos sean iguales 
u otro valor si son distintos. Por ello si: 








“DEBUG” >_stremp(s, “DEBUG”)=0 
_strempís, “DEBUG”) = NonZero 





A continuación, se compara el valor del registro eax que por convención 
contiene el valor de retorno de las funciones, en este caso cero o distinto de cero. 
Si no es cero la instrucción JNZ saltará a la izquierda (Mecha en verde), si es cero 
saltará a la derecha (flecha roja). El hecho de usar JVZ en lugar de JZ indica que se 
ha aplicado un NOT a la comparación. Esto se traduce en que: 
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stremp(s, “DEBUG™) -> Bloque básico derecha 
_strempís, “DEBUG”) -> Bloque básico izquierda 





Vamos ahora a analizar qué hace cada bloque básico. En el caso del bloque 
básico de la izquierda: 
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Lo único que parece que haga es montar una cadena de texto, luego calcular 


su tamaño con strien() para después enviar esa cadena por el socket mediante la 
función send(). A continuación va a un bloque básico que salta hacia arriba de nuevo 
(flecha naranja) 
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Cuyo bloque básico es este: 





Como se puede ver volvemos a la misma situación anterior mostrada en la 
Mustración 26. 
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Vamos ahora a analizar el bloque básico de la derecha para el caso default: 





328 REVERSING. INGENIERÍA INVERSA ORAMA 





Como se puede ver en la primera imagen, se muestra el mensaje detectado 
inicialmente en la venta de Strings” y más adelante se copia la cadena “/bin/bash” se 


usa la función dup2() para duplicar los descriptores 0.1 y 2: 


Para acabar haciendo un execvp() 


Lo que claramente muestra que se está ejecutando un intérprete de comandos 
y se está redirigiendo la entrada/salida/errores hacia un descriptor de ficheros. Si 
se pincha en el registro £AX se marcan todos y podemos ver la relación entre el 
descriptor de ficheros de la función dup2() y send() 





Por lo que se entiende que se quiere redirigir el flujo del proceso /bin/bash 





hacia el cliente conectado al que se le envian los mensajes 


Esto es sin duda una funcionalidad interesante, que permite al usuario abrir 
una consola con un intérprete de comandos. Ahora vamos a averiguar cómo es 
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ло del switch la variable s debe 





posible activarlo. Sabemos que en la opción por d 
valer DEBUG. Ya que s es la que se utiliza en la función recv() 





Queda claro que se debe enviar la cadena DEBUG al introducir las opciones 
del menú para llegar hasta aquí. Vamos a probar: 





Efectivamente, si escribimos ese comando, nos abre una shell donde poder 
ejecutar código en el servidor, supuestamente para depuración, pero no deja de ser 
un riesgo de seguridad, ya que cualquier puede llevarlo a cabo, 


Código fuente: 





Capitulo 8. APLICACIONES PRÁCTICAS 331 








Capitulo 8. APLICACIONES PRÁCTICAS 333 





334 REVERSING. INGENIERÍA INVERSA ORAMA 





8.4 CASO PRÁCTICO 3: ANÁLISIS DE UN FORMATO DE FICHERO DESCONOCIDO 


Obj 





vo 


En este ejercicio se va a mostrar cómo es posible llevar a cabo labores de 
ingeniería inversa para analizar un programa que maneja un formato de ficheros 
desconocido, de tal forma que seamos capaces no solo de comprender qué hace, 
sino de implementar un programa que sea capaz de estionar este tipo de 
ma objeto de nuestro análisis. 





ficheros totalmente compatibles con el prog 





Detalles 


Para la realización de este ejercicio vamos a utilizar un programa de ejemplo 






diseñado especialmente para este ejercicio, pero que responde perfectamente a una 
situación real, con la salvedad de la extensión de su código. Este programa está 
escrito en apenas 160 lineas de código, por lo que su análisis es perfectamente viable 
para lo que necesitamos en esta unidad. El código fuente completo se muestra al final 
del caso práctico. 


Partimos de un fichero binario que al ejecutarlo nos muestra lo siguiente: 





Nos indica que es requerido un argumento, que es el nombre de un fichero. 


No nos dice nada más, por lo que no sabemos a qué formato debe obedecer dicho 





fichero. Vamas a probar a introducirle un fichero cuyo contenido sean caracteres 


aleatorios, sin ningún sentido especial (finalizamos el contenido con Ctrl+D): 


Ahora vamos a ejecutarlo a ver qué sucede: 
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El programa ha tratado de manejar el contenido del fichero que le hemos 
proporcionado, pero dice que no es un fichero válido, Esto es, obviamente, debido a 
queno conocemos el formato de en la primera comprobación 
que ha realizado ha incumplido con el formato esperado y ha salido con un error, 





heros que reconoce, y 





Hasta aquí lo único que sabemos es que este programa tiene algún tipo de 
relación con una calculadora, como se puede ver por su banner. Es importante fijarse 
еп esos detalles, para intuir que cosas “debería” hacer y esto siempre es una ayuda a 
la hora de analizar qué es lo que hace. 





El siguiente paso es abrirlo con IDA Pro: 


SO AMA A DO 0 








Сото se puede ver en la ventana de funciones, no hay muchas funciones 
sin identificar (sub_xexxxs). Como en el caso anterior, esto no es lo normal en un 
programa real, por lo que aunque aquí sí podríamos analizar una a una las funciones 
para ver qué hacen, no es nada habitual hacerlo de este modo, ya que €s inviable 
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llevarlo a cabo en un espacio de tiempo determinado; además que no suele ser práctico, 


excepto si se pretende clonar por completo el programa. Normalmente se suele estar 





interesado en una parte concreta del programa, no en toda su implementación. Si 


se está analizando un formato de fichero o un protocolo de red, no interesa todo lo 





relacionado con la interfaz de usuario u otras funcionalidades no ligadas al formato 





o protocolo en sí 


Llegado a este punto hay que trazar una estrategia bien definida y tratar de 





eguirla sin desviarnos, para evitar perdernos por el camino. Hay dos estrategias 
claras: comenzar por la función start() e ir analizando qué hace hasta llegar analizar 


el fichero que se proporciona por línea de comandos: o localizar las funciones que 





stiona la apertura de ficheros, así como su manipulación (lectura/cscritura), 


El primer caso es viable en este ejemplo, pero no suele ser lo normal. Los 





programas suelen e 





-cutarse y quedar en “espera” a recibir “eventos” provocados por 
el usuario. En el caso de programas con interfaz gráfica, por los eventos relacionados 
con el ratón y los menús, y en el caso de servidores, provocados por las conexiones 
con el cliente que se suelen tratar en hilos y/o procesos independientes. Esto dificulta 
en gran medida un seguimiento lineal del flujo de ejecución desde start() hasta la 
“zona caliente” que es donde se ejecuta el código que buscamos, es decir, el código 


que interpr 





ta y manipula el formato de fichero y/o el protocolo a analizar. 


Vamos a llevar a cabo la segunda opción, localizar las funciones que 





stiona la apertura del fichero y su manipulación, en concreto su lectura inicial 
Para ello podemos utilizar cualquier herramienta de análisis de comportamiento 
vistas anteriormente, que monitorice las llamadas a sistema y poder determinar así 
qué funciones utiliza y poder posteriormente identificarlas en el desensamblado. 


En este caso vamos a utilizar el comando ltrace() con el que podemos ver 
lo siguiente: 





Como se puede observar, hace uso de fopen() y fread() para abrir el fichero 
ejemplo.raw y leer sus primeros $ hytes respectivamente. 
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Para identificar las zonas de código que hacen uso de estas funciones, 
primero vamos a enumerar las funciones importadas: 


тетсру 
fread 
malloc 


puts 
_ libe tart main 
тореп 

_gmon start_ 





Luego vamos a pinchar dos vecesen fopen(): 





Si nos posicionamos sobre la función (Jopen de color morado), podemos 
consultar las re s del código a esta función pulsando la tecla X: 
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Pinchamos dos veces sobre la primera opción: 


seguidamente pulsamos Ctr X: 








КТЕ T 
\ жес м 





тген] „тетет: 





Nótese que sì se pulsa solo X nos llevará al paso anterior. Para obtener 
el resultado deseado, con X se debe posicionar sobre _fopen en verde. Una vez 
pinchamos sobre dicha opción nos lleva al código que buscamos: 








L 


ORAMA Capítulo. APLICACIONES PRÁCTICAS 339 





Si observamos los bloques básicos cercanos a este código: 








Vemos cómo se utiliza printf() con una cadena de caracteres de error, que 
comienza con el mismo texto. 


Centrándonos en el bloque básico inicial, vemos cómo bifurca a un código u 
otro según el valor del registro EAX que contiene el resultado de la función_fopen. 
Si vemos la especificación de la función fopen() en el siguiente enlace: 





Y hitp://man7.org/limux/man-pages/man3 fopen.3.html 
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Vemos la interpretación del valor devuelto: 








RETURNVALUE ie 


Upon successful completion fopen(), fdopen() and freopen() return a 
FILE pointer. Otherwise. NULL 15 returned and errno 15 set to 
indicate the error 





Se observa cómo se devuelve un descriptor de fichero o NULL =0 en caso 
de haber algún error, ya que sabemos que el fichero se abre correctamente, porque 


devuelve un descriptor de fichero: 





Esto es, ya que si fopen() hubiera fallado, no podría haberse utilizado fread() 
correctamente. Teniendo en cuenta que devuelve 1 








ación de fread): 





Y si tenemos en cuenta la especil 


Y hip:/man7.org/limux/man-pages/man3/fread.3-html 


RETURNVALUE ш 


On success, fread() and furite() return the number of items read or 
written. This number equals the number of bytes transferred only 
when size is 1, If an error occurs, or the end of the file 15 


reached, the return value is a short 1tem count (or zero) 








fread() does not distinguish betueen end-of-file and error, and 
callers must use feof[3) and ferror(3) to determine which occurred, 
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Queda claro que fopen() ha devuelto un valor di 
al bloque básico de la flecha verde: 





ете а 0 y esto nos lleva 





O nora 


Cuando se diga BB:loc_wooooxx se refiere al Bloque Båsico localizado en la dirección 
Oooo etiquetado con el nombre loc ooon. 





Si analizamos el BB:loc_8048956 vemos lo siguiente: 


Ház 





Aquí tenemos una función con dos argumentos: 
sub_8048550 ([esp+Ich), [esp+14h)) 


Luego veremos de dónde vienen y qué contienen, pero ahora vamos a ir 
reconstruyendo un poco el código, nombrando algunas variables que sepamos ya qué 
finalidad tienen. Es el caso de la variable [esp+1Ch] que alma 
por fopen() y que, según la documentación, es un descriptor de fichero con el que se 
puede interactuar con el fichero cuyo nombre es el proporcionado a la función. Por 
ello vamos a nombrarlo como fd (file descriptor). 


ena el valor devuelto 
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Para renombrar un tipo de dato en IDA, basta con colocarse sobre él y pulsar 
N. Sin embargo, si nos posicionamos sobre el 1Ch del operando /esp+/Ch], veremos 
que nos sale lo siguiente: 


ааа. 00809893 


urn length cf new names 


Local name pref 


Lecalname 

J ineluée in rameslist 
Pubie name 
Autogenereted name 


meak name 





Si escribimos fd veremos lo siguiente: 


mAs 


Ва 
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ha creado una etiqueta en lugar de renombrar la variable. Y lo ha 


hecho porque no ha entendido que ICh sea ninguna variable. 





Si nos posicionamos al inicio de la función, podremos ver las variables 
locales y argumentos de función detectados por IDA: 





Aprovechamos para darle un nombre a la función y diferenciarla del resto, 
aunque no sepamos qué hace, para ello nos posicionamos sobre “sub_80488ED" y le 
damos a N, escribimos funcion] y veremos cómo ya ha cambiado su nombre 
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Cuando sepamos concretamente qué hace, podremos repetir el proceso y 
nombrarla más adecuadamente. Mientras tanto, al menos sabremos que la hemos 
visitado. 


Volviendo a las variables locales y argumentos, si pinchamos dos veces 


sobre alguno de los a 





¡mentos (arg_0 o arg_4). podremos ver la pila: 








Como se puede observar no se ha detectado ninguna variable local, sin 
embargo sí utiliza direcciones de memoria locales para almacenar nuestro descriptor 
de fichero, entre otras cosas. Esto es debido a que esta función está accediendo a 
istro ESP como base (Jesp+1Ch/). Mis 
mentos, porque son accedidos 


las variables con el re 
EBP como base, y es por esto que sí detecta los 
en base a EBP. Este comportamiento se puede modificar pulsando Alt+P que edita 
las propiedades de la función en curso: 


tras espera el uso de 
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Endara 


Enter sire st Go bytes) 


Saves regters 


Lora tune 





Bregua SE 





Como se puede observar, la opción BP based frame está marcada, y esto 


impide que reconozca las variables locales, aceedidas con el registro ESP como base. 


Si la desmarcamos y le damos a OK, veremos las siguientes variables locales y 


argumentos de función: 
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Y vemos como también la representación en fopen() ha cambiado: 


us 





Quitamos la etiqueta fd puesta anteriormente pulsando N al estar sobre ella, 
borrando el texto y pulsando OK y nos posicionamos sobre “stream” y pulsamos de 


nuevo N para renombrar por fin la variable a ‘fd: 








mos que automáticamente se han modificado todos los bloques básicos 
de la función. 


Ahora vamos a analizar el bloque básico al que lle 
un descriptor de fichero válido B8-loc_9048956 





mos tras ser asignado 
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Aquí vemos que se invoca la función sub_8048550 con otros dos argumentos: 
sub_8048550(|esp+20h+fa), lesp+20h+var_C]) 
Y vemos cómo el valor devuelto por la función es almacenado en la variable 


local var_8, y seguidamente comparado con 0. Si 
línea roja y si es mayor o 


1 valor es menor de 0, seguirá la 





ıal a 0, seguir la linea verde: 








Por el mensaje que imprimirá por pantalla (“ERROR- No se ha podido 
analizar el fich... ") si sigue la línea roja, se entiende que la función sub_8048550() 





iza comprobaciones sobre la validez del fichero proporcionado, por lo que vamos 
a analizar su código para ver si arroja luz sobre el formato correcto, y poder así 
cumplirlo y continuar por el bloque básico de la linea verde. Si pinchamos dos veces 
sobre la función vemos lo 





ШЕ 
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iombrar la función pulsando N estando sobre el nombre de la 


sub_8048480 
sub_80484F0 
sub_8048510 
sub_804853C 

funcion? 
sub_8048784 

funcion? 
sub_BOABSEO 
sub_80489F0 
04ВААА 





De esta forma, vemos cómo vamos identificando las funciones. Esto 
es importante si al navegar por el código nos perdemos y queremos recuperar la. 
posición de una función importante. Esta función tiene el siguiente aspecto (parecido 
a la función anterior) 





dk Graph overview 

















Esto es una estructura de IF en cascada. Si vemos los bloques básicos 
accedidos mediante las lineas rojas: 


Е 
5 
8 
E 
9 
5 
8 
3 
© 
2 
8 
S 
Е 
5 
8 
E 
5 
2 
5 
3 
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ORAMA 





Se observan tres bloques básicos parecidos, por ejemplo este: 





Шш = 





Que se copia bytes a direcciones. Si se pincha dos veces sobre esa dirección 
se observa que: 








Están alojadas en „bss, es decir variables globales sin inicializar. Si nos 
ho, vemos que entre las 





posicionamos sobre los bytes y pulsamos el botón der 
mación de carácteres, nos muestra *e oN”. Lo seleccionamos 





sugerencias, la de repres 
y con las siguientes podemos hacer lo mismo pero mås rápidamente posicionándonos 





pulsando R. Tras esta operación veríamos el siguiente mensaje: 
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Que leidos de derecha a izquierda y de arriba abajo, pondría “No es un 
fichero v lido”. 


Esta forma de almacenar las variables es común a la hora de traducir un 
strepy() de una cadena de caracteres a una variable. Al final vemos un valor numérico 
(0/0178) дие se copia en eax y luego continúa en el siguiente bloque básico: 








Ssimplemente finaliza la función restableciendo el marco de pila. Esto 
indica que cada bloque básico similar a este, copia un mensaje de error y devuelve 
un código negativo, tipicamente códigos de retorno de error. 


Ahora vamos al inicio de la función para ver qué comprobaciones provocan 
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Se ve cómo se invoca a la función fread() de la siguiente forma: _ 
freadílebp+ptr], 8, 1, fd); por lo que sabemos que ptr es un buffer en el que se 
almacenan los ocho primeros bytes del fichero. Primeros, porque ese descriptor de 
fichero no se ha utilizado antes en el programa. Tras leerlos se comparan los dos 
primeros bytes con 0x4643. Bien, ya sabemos que los dos primeros bytes del fichero 
deben contener esos dos bytes. Sì s 
bloque básico: 











imos la línea verde pasamos al siguiente 


ша __ 
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Si vemos cada bloque básico y su respectivo bloque básico con la flecha 
roja, obtenemos esto: 























Es dei 
A 
ТТ мот o 

EET чор a 


{ebptvar €] DWORD =0 


ORAMA 
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Ya que el contenido del ficherose almacena en la variable prr, y evidentemente 
esta no puede almacenar más de 4 hytes, y hay 8, donde además los cuatro primeros 
bytes se leen como WORD y los cuatro últimos como DWORD, nos hace intuir que 
se trata de una estructura. Por ello vamos a crear una estructura con esos $ bytes. Para 
ello pinchamos dos veces sobre pir, vemos la pila: 


Seleccionamos los 8 bytes y le damos a la opción “Create struct from 
selection”: 


Si nos posicionamos sobre cada una de ellas y pulsamos N podemos 
renombrarlas. Según los mensajes de 
elementos y quedaría así 


Una vez hecho esto, volvemos a los bloques básicos y vemos que 
automáticamente las variables han cambiado, pudiendo ver esto: 









-ror, procederemos a renombrar estructura y 
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Ahora vamos a centramos en la ùltima parte de código de la función: 





Como se puede observar en BB:loc_8048705, se utiliza ptrmayorQueCero 
para mostrar un mensaje por pantalla: “/+/ %i operaciones identificadas.In”. Y 
reservar espacio de memoria con malloc(). Esta variable dinámica se almacena en la 
5 decir, el puntero al espacio reservado, se asigna a arg_4 y luego se 
comprueba que no se: 








variable arg_4, 











igual a cero: 


ORAMA 
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Si es igual a cero (flecha roja) muestra un mensaje que dice que no hay 
espacio suficiente en memoria. Si es distinto de cero, utiliza_memcpy() para copiar 
el contenido de ptr a arg_4:_memcpy([ebp+arg_4), [ebp*ptr], 8); por lo que arg_4 
también será una estructura header_t. Tras la copia, se establece el valor 0 como 











valor de retorno y se sale de la función. Así que renombraremos de nuevo la función 
como “checkAndGetHeader()” y volvemos a la función que lo invocó, donde vemos 
que automáticamente se cambió el nombre 







зв вино 
Д наво 
зр ав 







ub, 8048060 
эш Саба О 





Como sabemos que arg_4 apunta a una estructura del tipo header_£, ahora 
vamos a establecer var_C como un puntero а header_1. Para ello nos posicionamos 
sobre var_C y pulsamos N y escribimos el nuevo nombre pheader: 
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Por último vamos a analizar la última parte de esta función: 





Vemos que en BB:loc_8048990 se invoca la función sub_8048784 con los 
argumentos: 


sub_8048784(fesp+20hżfd], [esp+20h+pheader]); donde si el valor 
devuelto es menor que cero, se imprime el mensaje: 


“ERROR: No se han podido llevar a cabo [...”; que si se pincha dos veces y 
visita la cadena se observa el mensaje completo: 


Esto indica que esta función nueva, realiza los cálculos sobre los datos, se 
entiende que proporcionados сп el fichero. Para arrojar más luz, vamos a entrar en 
esta nueva función y renombrarla como doCales. 
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Z omen start_ 
Z libe start main 


7] sub-Boses1o 

FJ sub B053 
cneckandGetHeader 
поса 


Une 17 o 23 


sl, Graph overview 





Por el diagrama de los bloques básicos vemos cómo hay varias 
comprobaciones y un bucle, identificado por la flecha azul de la derecha, que va del 
bloque básico más grande al segundo empezando por el principio. Esto puede indicar 
que recorre los datos del fichero realizando los cálculos, saliendo al detectar algún 
error, o llegar a la condición de parada. 








Vamos a ver el código para poder entender correctamente qué hace. Como 


también vemos que utiliza ESP para acceder a las variables locales, vamos a 
desmarcar EBP de la función entrando con Alt+P. Tras esto, podemos ver cómo las 


variables locales cambian: 
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Aquí vemos cómo se inicializan las variables заг. 10 = 0 y var_11 = 0:20, 
luego se reservan OXx0C Aytes con malloc() y quedan apuntados por ptr. Se inicializa 
también var_C = 1 y se salta incondicionalmente al siguiente bloque básico. 
Esta variable parece ser un contador para el bucle cuyo bloque básico inicial es 
BB:loc_80488D0, el previo a la inicialización de var_C. Si nos posicionamos sobre 








él y pulsamos X, vemos los accesos: 


ткт 
ИКЕ 
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tura W y dos de lectura R. Los de 
y uno que suma 1 





Esto indica que hay dos accesos de e 
escritura son el de inicialización en el que estamos posicionado: 
Está claro que estamos hablando de una variable de incremento del bucle. Por lo que 





la renombraremos como “i 





‘omprucbasiedx([ehp+i])esmayoro igual aeax([[ehp+arg_4]+4]). 
_4 аршиа а рйеайег, por lo que 





Aquis 
Ya que arg 4 según la invocación a la función a 
podemos definirla del tipo header_t. Se puede hacer automáticamente posicionándose 





sobre arg_4 y pulsando T 





sta forma vemos que el elemento “mayorQueCero” contiene el número 


De 
de iteraciones de esta función. Con esto ya tendriamos los datos suficientes para 





Pro encontrado en: www.eybooks, com 


poder generar un fichero con una cabecera válida: 





9 Descripción 
0000 Magic = 0x4643 
ою? Version >= 1 


0008 N" iteraciones> 0 
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A modo ejemplo rápido podríamos generar un fichero con una cabecera 
válida en Python con el siguiente código: 








Donde el programa mostraría lo siguiente si analizara dicho fichero 





Сото ѕе puede observar, hemos conseguido que reconozca la cabecera, que 
identifique correctamente el valor $, y ahora nos descifra que ha tratado de analizar 
una operación, pero es desconocida, Vamos a seguir analizando el código por donde 
nos habíamos quedado: 











Tras detectar bien el numero de iteraciones, pasamos al B2:loc_8048782 
que invoca a la función: _fread([ebp*ptr], 0xC, 1, Jebp+stream)). Es decir, que le 
los siguientes xC Bytes del fichero y los copia al espacio dinâmico reservado por 
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malloc() apuntado por ptr. Se comparan los cuatro primeros bytes con el valor 1 





jal se sigue la flecha verde y si no la roja. A continuación se muestran los 
bloques básicos implicados: 








Como se puede observar el BB:loc_804881A copia el mensaje de error que 


vimos anteriormente. Para no llegar aquí, esos primeros 4 bytes leidos deben valer 


102 





Si vale 1: 
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Si pulsamos sobre 2Bh con el botón derecho, vemos que nos sugiere el 


carácter “- 


Y vemos cómo se lleva a cabo una suma entre: 





add eax(/[ebp+ptr]+8)), edx([lebp+ptrJ+4J) 


Igualmente en el caso 2 


sub ecx([[ebp+ptr]+8]), eax([lebp+ptr]+4]) 





Y el resultado de la operación en ambos casos se almacena en var_10, por 
lo que será renombrada como resultado y el simbolo de la operación en var_/1 que 
renombraremos como op. El último bloque básico de la función muestra claramente 
esto que acabamos de analizar: 





Aquí se invoca la función: 





_primft™'|-] Operación N” %i ', i, [lebp+ptr]+4], 
op, [lebp+ptr]+8], resultado). que imprime un mensaje que muestra claramente la 
finalidad del contenido del fichero, e incrementa en 1 la variable i. Esto inicia el 





bucle que leerá OxC ytes nuevos del fichero hasta legar al número de iteraciones 
contenido en el fichero. Estos OxC bytes tienen la siguiente estructura: 


Libro encontrado En: Www.eybooks.com 
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2 


0004 Operando! 
оок Operando? 





ORAMA 


un fichero que realice cinco 





Con esta información ya podemos cr 


operaciones en Python con el siguiente código: 





el fichero resultante muestra lo siguiente: 





гог, podríamos intuir que no hay más código que 





Ya que no muestra nin 


analizar y que el formato de fichero está bi 





Si vemos el resto de código, de la funcion? 
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Vemos que devuelve O y sale de la función. Si subimos arriba y 
posicionándonos sobre “funcion!” pulsamos X veremos: 


ШЕТ 





Capitulo 8. APLICACIONES PRÁCTICAS 365 


Que es invocada por start(), por lo que está funcion!!() en realidad era main() 
y al finalizar, el programa llega también a su fin. 


Con esto ha quedado explicado, de forma detallada, la manera en la que se 
puede llevar a cabo un exhaustivo análisis de código e ingenieria inversa para poder 
obtener el formato de un fichero binario tan solo con un programa que sea capaz de 
interpretarlo. 


Código fuentes 








Capitulo 8. APLICACIONES PRÁCTICAS 367 








ORAMA 


Capítulo. APLICACIONES PRÁCTICAS 269 





8.5 CUESTIONES RESUELTAS 





8.5.1 Enunciados 


1 


En el caso práctico 1, ¿de qué tipo era el fallo de seguridad?: 


a. Integer Overflow 
b. Heap Overflow 
e. Stack Overflow 
d. Race Condition 
e. Denial of Service 


¿Qué es un PoC?: 


a. Program of Code 
b. Pass of Code 

e. Program of Concept 
d. Proof of Concept 


¿Qué es SEH?: 


Structured Exception Handling 
Structure Exception Handler 
Stack Exception Handling 
Stack Exception Handler 


En el caso práctico 
su nombre original? 
a. Verdadero 

b. Falso 






, ¿todas las funciones pudieron ser identificadas con 








En el caso práctico 2, ¿en la ventana de Strings se podían ver todas las 
cadenas de caracteres): 


a. Verdadero 
b. Falso 


En IDA Pro, al posicionarse sobre una constante numérica, ¿con qué tecla 
se puede codificar a un carácter ASCII?: 


ens 
>ez 
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7. En IDA Pro, al posicionarse sobre una variable o función, ¿con qué tecla 
se puede modificar el nombre de la misma?: 


aN 
b. U 
c. A 
dR 


8. En el caso práctico 2, ¿con qué nombre identifica IDA Pro el buffer 
que utiliza para almacenar la entrada y salida hacia la conexión con el 
usuario? 


a. buffer 
b. buf 
ts 
d. Ninguna de las anteriores. 

9. En el caso práctico 3, ¿ha sido posible guiarse por las cadenas de texto 
para intuir el uso de determinadas variables?: 


a. Verdadero 
b. Falso 

10.En el caso práctico 3, ¿ha sido posible reconstruir el formato para poder 
generar ficheros válidos”. 


a. No 
b. Solo parcialmente 
e. Si 


8.5.2 Soluciones 
Le 
24 
за 
4.b 
5.b 
6.4 
та 
ве 
9.a 
10.e 
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